@DoingMath2018 The unevaluation quotes merely delay evaluation, and the quoted expression is not inert. Each full evaluation will strip off a set of uneval quotes. Strip off them all, and you get your original error. It's fragile because several common things induce an evaluation (eg. passing in as argument to a procedure call).

That's why I gave my second example, using %plot to obtain an inert form. The call to %plot can be evaluated, multiple times, without that same problem. When you're ready to produce the actual plot -- following substitutions and manipulations, etc -- then you can utilize the value command on it.

@Scot Gould Yes, failing to hit the upper end-point (due to roundoff error making the last value exceed the bounds) is somewhat understandable. But missing two values is odd.

By the way, I submitted a request this past year for an enhancment to seq. Instead of supplying the float increment as an option I asked to be able to supply the number of values. Eg,
   seq(a..b, number=4);     # or similar syntax
The idea is twofold: 1) To avoid roundoff issues and always hit both end-points, and 2) To avoid fencepost mistakes such as accidentally dividing b-a by N or N+1 instead of N-1, etc.

@DoingMath2018 His 3rd example is in the same vein as my first, using unevaluation (single right-quotes) to delay evalution.

There are many common scenarios in which such a quoted expression gets accidentally evaluated. For example, by passing it around as argument to some procedure call. It can be a somewhat fragile mechanism.

But even if you do not intend on passing the unevaluated call, there are still more graceful mechanisms.

For example, using a procedure.

Or substituting into the arguments of the plot call rather than into an unevaluated plot call. I think that the first of these is less contrived than the second.
  plot(x, eval(x = 0 .. a, [a=3]));
  eval('plot(x, x = 0 .. a)', [a=3]);

@Scot Gould I'm sorry, but I don't understand your comment.

I use ':-size' to try and protect against the case that the user might have assigned some irrelevant value to the global name.

I'm not sure what you are saying about images and global sections.

Note that so-called plot persistence can sometimes have an effect -- if you get rid of a plot's size option then the GUI remembers the old dimensions used to render in that output area. If a new size is not explicitly provided then it can happen that the GUI re-uses the old dimensions. Removing the old output, first, then displaying the new, gets rid of that effect. I'm not sure if you ran into this behavior, but it can be confusing when trying to figure things out.

There is no attachment.

@sunit It's easy enough to make a reusable procedure for it.

You can apply it to each equation, or to a system (set) of them.

question_sunit_ac2.mw

By the way, if you were to go with Kitonum's suggestion to convert to rational, then in general it would be better to substitute using convert(par,rational,exact) instead. (Don't incur possible roundoff error in general, if you don't have to.) I didn't show that way because it produces a result with rationals instead of the short floats, so it doesn't answer the question you actually asked.

@eslamelidy You can use the plots:-display command to combine plots.

x_e_-.008_2_ac.mw

@emendes You could somewhat reasonably extended your catch to , say,

   catch "time expired","does not exist","invalid input","at offset":

You could also insert another catch clause (a try..catch can have several, which are checked in succession). It is sometimes useful to put in, as a final catch clause, a plain,

   catch:

to trap any remaining errors.

Then you may deal with that as you see fit. You could print something or take some suitable computational action, then optionally rethrow an equivalent error message using the error statement.

See also the use of the StringTools:-FormatMessage command, and lastexception, in an Example on the ?error Help page. This is sometimes useful, for re-throwing a message, turning an error into a warning, or what have you.

What I meant about flags is that in some complicated situations the preliminary actions done within the try clause (prior to an error) might change the state of some variables, etc. You might have a situation in which you need to reset certain things in a finally clause, and so it can help to record the initial status or successes at earlier stages.

Breaking up a try..end try with an overly involved try clause into smaller steps can sometimes help, if it becomes unwieldy.

@Carl Love Something like this?

Download genglobal_ac3.mw

@nm Ok, you did not state in the original question that you wanted repeat calls to utilize the same dummy name. But as I mentioned, it could be accomodated.

Do you want different ode problems involving the same third argument to utilize the same new name? I'll guess that is so, too.

Download genglobal_ac2.mw

It's always better to describe as much about your requirements as you can up front.

@Ali Hassani Please keep this discussion centralized, instead of spawning off an unconnected new Question thread.

@nm It's just not clear whether the call to currentdir and the reassignment to libname occur within the body of the test procedure, or not. Carl's Answer is supposing that they do not. It's still not clear.

@Carl Love It is not clear from the code fragments posted to date in the Comments that the two statements (identified by the OP as being problematic) are outside the definition of the procedure assigned to module local dsolver_test:-test .

The Comment was posted with this,

dsolver_test := module()
option package;
....
export test:=proc()
local main_dir := "C:/tmp/current_version";
...

   #these two lines were the cause
   currentdir(main_dir):   
   :-libname := main_dir, :-libname;

.....
     foo() #foo is just another local proc in this module
.....
end proc;

Those two lines appear before the end proc that appears to close the definition of the procedure assigned to test. So they appear to be part of the procedure body, in which case your explanation does not apply to this case.

However, since the code fragments also lack an end module it is possible that end proc is a typographical error and is intended to represent an end module, and that the actual end proc might be (as yet unshown and) before the two lines in question. In that case your explanation could be germane.

I find the provided code fragment to be a muddle. It's a pity that the OP could not take the time to provide actual full code to reproduce the issue. It seems to me that the OP has merely changed coding methodology without doggedly pursuing the cause and understanding of the original problem.

@Rouben Rostamian  FYI, the nicer form of the integration (involving the GAMMA call rather than EllipticK and EllipticE calls and the imaginary unit) is obtained directly from the nested int call in Maple 2019.2 and earlier (back to at least 16.02).

It can also be had directly in Maple 2020 with the meijerg and meijergspecial methods, eg.

f:=x->sqrt(x^(2/3)-x^2):
int(int(x,y=-f(x)..f(x)),x=0..1,method=meijerg);

                          2  1/2
                GAMMA(3/4)  2
            2/5 ----------------
                       1/2
                     Pi

There are also a few simplification weaknesses lying about, eg. converting EllipticE(I)
to GAMMA_related, etc.

I shall submit a bug report.

Provide the example that reproduces the problem with an .mla archive, if you want us to figure out what's going wrong in it.

By this I mean code that defines the module, and the code that stores it in a .mla Library Archive, and the example that subsequently does not run as expected.