I see. Nevertheless, it seems to me more informative on this problem a comparative plot like:

plot([uData,v],t=0..5);

I see. Nevertheless, it seems to me more informative on this problem a comparative plot like:

plot([uData,v],t=0..5);

I get instead:

eval(uData, t=1);
                                   undefined
eval(v, t=1);
                                   undefined

as both expressions contain a term Heaviside(t-1) or similar.

I get instead:

eval(uData, t=1);
                                   undefined
eval(v, t=1);
                                   undefined

as both expressions contain a term Heaviside(t-1) or similar.

This is an example of the well known issue of global vs local name clash: the procedure expects an unassigned global name as argument, but receives an exported local name instead which was bound to the same name by use of with, as Preben said. In this example plottools:-line, whose value is a procedure.

Certainly, this issue and its "solution", globalizing the name by hand, using the collon dash prefix, is documented in ?with. In this example, :-line, as Preben also said. Yet, the status of this issue and its solution is disputed. For some people this is at most a weakness and the globalization trick is all that is needed. Or, in any case, a better, automatic solution is not a priority. For me, it is a design bug that should have been solved years ago.

With tens of exports by a typical package, and tens of options in commands of another package, say, chances of name clash are, on the one hand significant, and on the other hand difficult to foresee. Thus, most likely, the user will realize that something is wrong only after receiving the error message. Then, an experienced user may remember to use this globalization trick, but most users will not realize what happens and will be left clueless as they are using the command as instructed in its help page. Moreover, as no warning is produced by name rebinding as it occured by executing with before of Maple 10.

The interesting thing is that better solutions seem possible. On the one hand, some top level and package commands give context to the arguments being passed, which get "recycled" looking for a match to valid arguments. This example was provided by the developer some years ago:

> M := module() export erf; option package; end module;
> with(M); # here erf gets rebounded to M:-erf

                                [erf]

> FunctionAdvisor(syntax, erf); # even so, there is no problem here

                                erf(z)

Also, ?coercion , introduced in Maple 16, could provide another way.

Certainly, poor documentation of this facility is the systematic complain that I have read along the last 15 years from those (few) users that tried to use it. For background, see this thread.

Certainly, poor documentation of this facility is the systematic complain that I have read along the last 15 years from those (few) users that tried to use it. For background, see this thread.

@Markiyan Hirnyk 

Actually, how to define the rule may depend on some details missing in your question, so that I am guessing them. If you mean the transformation a^infty -> infty for a possibly symbolic expression a such that the condition a>0 is given by an assumption, then the corresponding rule should be a conditional one. In this way, the assumption a>0 can checked by an is call in the condition part of the rule, where the binding for a has already been done:

> r:=conditional(a::algebraic^infty=infty, _is(a>0)):
> applyrule(r,a^infty);
                                      infty
                                     a
> applyrule(r,b^infty) assuming b>0;
                                     infty
> applyrule(r,2^infty) ;
                                     infty

Note that inert forms of the function names are required in the condition part, where the inertization is done by an underscore prefix, here _is  (this syntax is peculiar to the PatternMatching package).

@Markiyan Hirnyk 

Actually, how to define the rule may depend on some details missing in your question, so that I am guessing them. If you mean the transformation a^infty -> infty for a possibly symbolic expression a such that the condition a>0 is given by an assumption, then the corresponding rule should be a conditional one. In this way, the assumption a>0 can checked by an is call in the condition part of the rule, where the binding for a has already been done:

> r:=conditional(a::algebraic^infty=infty, _is(a>0)):
> applyrule(r,a^infty);
                                      infty
                                     a
> applyrule(r,b^infty) assuming b>0;
                                     infty
> applyrule(r,2^infty) ;
                                     infty

Note that inert forms of the function names are required in the condition part, where the inertization is done by an underscore prefix, here _is  (this syntax is peculiar to the PatternMatching package).

Note that the 3rd rule infty+infty = infty is redundant as its lhs automatically simplifies to 2*infty, and this case is already covered by the 2nd rule. Similarly, in the 4th rule infty*infty = infty, the lhs automatically simplifies to infty^2, so that the other powers are not transformed:

applyrule(eqs,infty^3);
                                  3
                             infty 

Presumably, this rule should read infty^n::posint = infty.

Note that the 3rd rule infty+infty = infty is redundant as its lhs automatically simplifies to 2*infty, and this case is already covered by the 2nd rule. Similarly, in the 4th rule infty*infty = infty, the lhs automatically simplifies to infty^2, so that the other powers are not transformed:

applyrule(eqs,infty^3);
                                  3
                             infty 

Presumably, this rule should read infty^n::posint = infty.

In addition to Robert's comment on diverse conventions used in different parts of Maple, see these extracts from some relevant help pages See also the containing thread, and this other one, for more background.

I have to repeat what I have said then: for me, user friendliness means consistency throughout the whole system, much more than fancy GUI toys.

In addition to Robert's comment on diverse conventions used in different parts of Maple, see these extracts from some relevant help pages See also the containing thread, and this other one, for more background.

I have to repeat what I have said then: for me, user friendliness means consistency throughout the whole system, much more than fancy GUI toys.

Indeed, I have observed already that trigsubs has been rewritten as a module. The names of the transformational formulas are located in the table trigsubs:-subs_table, populated by the execution of trigsubs:-ModuleLoad:

kernelopts(opaquemodules=false):
trigsubs:-ModuleLoad():
indices(trigsubs:-subs_table);
        2                                _N
[cos(_X) ], [sin(_X) - sin(_Y)], [sin(_X)  ], [cot(_N _X)], [tan(_X + _Y)],
    [sin(_X) cos(_Y)], [cos(_X)], [cos(_X) sin(_Y)], [sin(_X) + sin(_Y)],
            2                                                           2
    [sin(_X) ], [csc(_X + _Y)], [csc(_X)], [cos(_X) + cos(_Y)], [tan(_X) ],
            2                                                            2
    [sec(_X) ], [cos(_X) sin(_X)], [cos(_X) cos(_Y)], [tan(_X)], [csc(_X) ],
    [sec(_X)], [cot(_X + _Y)], [sin(_X) sin(_Y)], [sin(_N _X)], [sec(_X + _Y)],
                       2
    [cot(_X)], [cot(_X) ], [sin(_X)], [cos(_N _X)], [tan(_N _X)],
                            _N
    [sin(_X + _Y)], [cos(_X)  ], [cos(_X) - cos(_Y)], [cos(_X + _Y)]

lprint(op(1,trigsubs:-subs_table));
table([(cot(_X+_Y))=["sum expansion" = (-1+('cot')(_X)*('cot')(_Y))/(('cot')(_X
)+('cot')(_Y))],(cos(_X)*sin(_X))=["double angle" = 1/2*('sin')(2*_X)],(cot(_X)
...

This table is the basis of the trigsubs own pattern matcher, which is even less documented, and neither too reliable nor extensible. Its limitations are not being changed by this labelling feature. Just compare:

trigsubs(sin(x),annotate=true);
["odd function" = -sin(-x), "double angle" = 2 sin(x/2) cos(x/2),
                              1                      2 tan(x/2)
    "reciprocal function" = ------, "Weierstrass" = -------------,
                            csc(x)                              2
                                                    1 + tan(x/2)
    "Euler" = -1/2 I (exp(x I) - exp(-I x))]

trigsubs(-sin(x),annotate=true);
Error, (in trigsubs) expecting a product of two functions but got -sin(x)

Consequently, if you select in Standard GUI the output of sin(x) you get a popup with a "Trig Identities" option, but no such option occurs if you select the output of -sin(x). This means, in my opinion, that this clickable stuff is more cosmetics than substance.

So, I am not convinced of tweaking with this code too much. in my opinion, there should be a common pattern matcher used throughout the system (actually a pair: a syntactic pattern matcher in the kernel and a mathematical pattern matcher in the library on top of it). 

Thus, I would go rather with a simple procedure as sketched here:

ts:=proc(ex,tr::string)
local t;
t:=table(trigsubs(ex,annotate=true));
t[tr];
end proc:

ts(sin(2*a),"double angle");
                                2 sin(a) cos(a)

ts(cot(2*a+b),"sum expansion");
                              -1 + cot(2 a) cot(b)
                              --------------------
                               cot(2 a) + cot(b)

Daniel, what about runnig Maple 13 in a virtual machine with Fedora 14 as guest OS, say?