@mehdibgh I assume that in the real problem you are using Matrices or Arrays, which are mutable Maple structures (in this context, mutable means they can be changed without reallocating memory). If possible, the best approach would be to continually reuse an assigned Matrix, or small number of Matrices. In the toy problem you gave, my suggestion computes a Matrix with symbolic values one time, however, the following loop then generates a separate Matrix with each increment.  If you don't need to save all the resulting matrices, you could do something like the following
 

U := simplify((A+1/A).B);
V := copy(U); # one time allocation of V
for s to n do
    subs['inplace'](t=s, V); # modify V 
    # do something with V     
    V[] := U[];              # transfer content of U to V, but don't allocate more memory
end do:

@pallav It's called the empty symbol.  Look for help page for emptysymbol or the expression itself (``).  Because it typically doesn't display, a function call using the empty symbol as the function will appear as a set of parentheses enclosing the arguments to the function call. 

Note, the help page for the emptysymbol is a bit strange in that the third paragraph describes how one can assign an expression to the emptysymbol (a roundabout way of saying it isn't protected). I cannot think of any good reason to do this. A nice feature of the empty symbol is that, as Kitonum shows, the expand procedure will undo it (that fact should really be mentioned in the help page).

That change is not advisable.  Note that in your case, the parameter s_rel0 = 0, so if the absolute value was used, contact would effectively never occur. The elasto-gap device is supposed to model lift-off (i.e. force goes to zero when spring lifts off a surface); as such it has to consider the sign of the distance.  The confusion comes about because, when thinking about physical distances it is natural to consider only the magnitude and not the sign. 

@Christian Wolinski Thanks for the correction.

My first version of Maple was Maple V.  It included a hard-cover Maple V Language Reference Manual, which is close to what you want, but isn't really more useful than the current programming guide, though it did contain a formal syntax of the Maple language written in BNF grammar. 

@Carl Love Am submitting a request for enhancement to add a suitable ModuleType method to MutableSet.

@AmirHosein Sadeghimanesh Either works.  The second call returns false because you used test2, not test.

@Carl Love Thanks, makes sense.  A partial workaround would be to do

M := MutableSet(...):
andseq(m :: sometype, m = M);

Could you enter an example that generates the error.   The following works as expected
 

M := MutableSet(a,b,c):
type(M, 'MutableSet');  
                                                 true

@Rouben Rostamian  I may have not pushed a current version in awhile.  It's supposed to install an examples subdirectory. Will look into that tonight.

Answers

1. Typically you execute the shell script from a shell.  The example shown in the help page undoubtedly causes some confusion (there the Maple command Bark:-ShellCmd is used to execute the command because Maple help pages typically only show Maple commands).

2. The shell script is not self-contained.  It requires Maple.  The Bark:-CreateScript command creates two files: the shell script, which is small (5 lines) and an mla which the script uses.

3. The purpose is to allow doing a particular task from the O/S command line, using Maple.  For example, one of the tools I created with it will print embedded components of a selected type (Button, ComboBox, etc), with all or selected attributes (id, caption, code, etc) of a given Maple worksheet.  It also allows modifying selected attributes.  Mainly I use it for tools I use at work.   Before creating Bark, I would typically create a bash script that processed the arguments then called Maple.  Now I can write everything in Maple, which I prefer.

Update

There appeared to be a bug in Bark:-InstallExamples, which you should normally call from the Bark intro page when installing the package.  I've uploaded a revised version.  It includes three examples: hello, mhelp (for creating a help database from mw files), and checkmo (useful with MapleSim for checking/listing/printing the content of MapleSim modelica libraries).

These are all excellent suggestions, though not sure about 3. Say the components were arranged with flow from left to right.  To flip horizontally each component would be horizontally flipped (locally) and also the left-most would be swapped with the right-most, etc.  An interesting conceptual way to accomplish this, without a specific GUI operation, would be to combine the components into a subsystem, then flip its block and then apply your proposed undo subsystem operation (5).  

@nm copy(old_object) calls Object(old_object), so if the ModuleConstructor requires additional parameter, you'll have to use the second version.  If no additional parameters are needed, then either works and the direct call to Object avoids some negligible overhead.

Note that if the additional arguments will be assigned fields of the object, which is frequently the case, then you can make them optional in the following manner.
 

person := module()
option object;
local name :: string := "";
    
export
    ModuleCopy :: static := proc( self :: person
                                  , proto :: person
                                  , name :: string := proto:-name
                                );
        self:-name := name;
    end proc;
    
export
    GetName :: static := proc( _self )
        name;
    end proc;
    
end module:

p1 := Object(person,"me");

p2 := Object(p1);
GetName(p2);   # returns me

Doing so causes the new object to have the same values as the copied object, as shown above.

@nm The proper way, as I believe you figured out, is to use the Object procedure to copy an object.  Using copy(obj) already does that (invokes Object(obj)), but fails if the deep option is passed.

@nm In your second example, there is nothing special about the use of _self; you can replace it with, say, self, and it behaves the same.

My hand-waving as to why the failure occurred is presumably inaccurate. However, consider the following method added to your object:

export foo :: static := proc(_self)
    proc(self :: person) self:-age end proc(_self);
end proc;

That raises more-or-less the same error when the object class is created.  The anonymous procedure is not a local/export of the object and so has no access to the objects locals.  Maybe it should, but currently Maple's objects don't work like.  On the other hand, that isn't consistent with your use of overload (where the overloaded procedures can access the object locals).  My speculation is that overload has not yet been extended to handle the special case of the _self formal parameter.

@Carl Love A reasonable point. I speculate that it came about because the special nature of _self was introduced after objects.  That may also be why it is best used without a type declaration, that is, if _self as a formal parameter is given a type declaration it then behaves like an ordinary parameter.