@Carl Love The version with dim declared local (as vv had done) is better, by way of being safer.

The slightly modified createModule2 example below, in which the global :-dim is utilized within the constructed module export det, will go wrong if dim does not scope out to a local for that subs call being made inside det.

The local dim declaration could be part of either createModule2 (as vv had it, and as I had it in my unapply workaround above) or the constructed anonymous module.

If you run the code below, without dim declared local within createModule2 or the constructed module, then you should be able to see what I mean.

restart:

dim:=13.5:

with(LinearAlgebra):

createModule1 := proc(dim::posint)
    module()
        export det;
        det := ((x::Matrix(1..dim,1..dim)) -> :-dim*Determinant(x));
    end module
end proc:

createModule1(       2 ):-det(IdentityMatrix(2));

                              13.5

createModule2:= proc(A::Matrix(square))
uses LA= LinearAlgebra;
     module()
     local dim;
     export 
          det:= subs('dim'= LA:-Dimension(A), (x::Matrix(dim))-> :-dim*LA:-Determinant(x))
     ; 
     end module
end proc:

eval(createModule2(Matrix(2)):-det);

          x::(Matrix(2, 2)) -> :-dim LinearAlgebra:-Determinant(x)

createModule2(Matrix(2)):-det(IdentityMatrix(2));
                              13.5

And I've submitted a separate report that the following crashes the kernel. An error message about invalid substitution would be gentler.

p:=subs(y=(2,2),proc() :-y; end proc);
                          p := proc() :-2, 2 end proc

p();
Execution stopped: Stack limit reached.

@John Fredsted That the second one does not work.

I have submitted a bug report.

@John Fredsted I notice that in Maple 9.03, 9.50, and 10.03 the first way does not work either (producing the same error), but the first works in versions 11.00 onwards.

Interesting question. I'm a tiny little surprised that either work. While we await the light, here is a workaround for the LOCAL `dim` case,

createModule2 := proc(A::Matrix(square))
    local dim, x;
    dim := LinearAlgebra:-RowDimension(A);
    module()
        export det;
        #det := unapply('LinearAlgebra:-Determinant'(x),x::'Matrix'(dim,dim));
        det := codegen[makeproc]('LinearAlgebra:-Determinant'(x),[x::'Matrix'(dim,dim)]);
    end module
end proc:

I mention `makeproc` as well as `unapply`, because the former can be more powerful, I wasn't sure how complicated your constructed module's proc might be, and to what degree this is a toy example.

acer

Your followup question is also about a topic that is very involved. Maple's type system is not hierarchical. For a given expression a variety of type-checks are done, results being encoded numerically, and then recursive lookup done to figure out what items belong in the menu. In order to be more efficient this makes use of tree structures, records, and recursion. Done naively the menu construction could be very expensive, and one consequence of the current implementation is that the whole process is rather opaque.

I'll dig some more and if I find a reasonably convenient way to query and display what (I think that) you're asking I'll follow up. But I wouldn't hold your breath..., sorry.

On the off chance that what you really want to do is figure out how to customize the context-menus so that your favoured items show more often, then that is actually quite straightforward. You could read the various ContextMenu help pages that cover it. I've made a few posts that utilize this functionality in the past, see 1, 2, 3, 4.

I can also mention that you can programmatically obtain a representation of the context-menu items that would appear for some given expression. For the expression a=0 , where a is the unassigned name, one way to obtain a terse representation of the menu items would be,

  ContextMenu:-Test:-GetGeneratedMenu( a=0 );

while a more detailed and more convoluted representation could be obtained using the command,

  ContextMenu( a=0, true );

@Markiyan Hirnyk Yes, I am quite aware that was the original question. My answer relates to how the context-menu can be augmented with some additional commands (which can also induce some replacement) and I explicitly stated as much.

The reason I gave the answer is that it is the kind of question that new users ask, and it may still be of some value to the Asker or others.

The precise answer to the original question is no, it cannot be done.

Apart from the sheer magnitude of the task there are considerable difficulties in the way of a user trying to achieve such an enhancement programmatically. One obstacle is that various commands have alternate calling sequences, the legal set of which are not programmatically available. While many newer commands use the builtin parameter-processing for proc definition there are many which do not -- the logic of what is acceptable as command arguments cannot itself be picked apart and massaged into a scheme for automatically generating all valid menu actions. This is also true of many command which do use such parameter-processing. A very hard part woudl lie in programmatically generating the menu items for all calls where additional arguments are legal, or required. This is on top of the notion that such a complete menu system would be so large that using it would likely be impractical.

There is much more involved in the general topic of the question asked here. For one thing, it is important to note that the ability to write arbitrary programs in the Maple language means that there will always be a much broader set of things that can be done with custom programming than can ever be done in practice with any finite set of context-menu items. Interactive Maple use via context-menus may be great for students learning math but it can never match the power of a programming language for more general computation. Hence I tailored an answer that may be useful to students.

@tomleslie Since you now indicate your initial response to my Answer wasn't directly related to my Answer (or its statements about calling the print command from within Document Blocks) then I've changed your Comment into an Answer.

When a Document Block is not in "expanded" state then it consists of a pair of Execution Groups. The output of the first is supressed and the input of the second is supressed from display. The output of the first is used as input for the second, behind the scenes in the GUI when the Block is "collapsed" = not "expanded". This scheme causes all normally printed output to be queued (as the redirected material) and only printed altogether once the first Execution Group (containing the user's command) finishes computing.

If you execute the code in either of the two collapsed Document Blocks in the attached Document you should see that the printed results for either collapsed Block are displayed in two clumps. The individual printed statements do not get printed one at a time, asynchronously. The same goes for lprint, printf, and userinfo statements.

doubters.mw

If you were to expand either one of the two Document Blocks (select with mouse, menubar "View" submenu) then you'd see a pair of Execution Groups for each, with red prompts. If you were to execute only the first of the pair of Execution Groups in an expanded Document Block then the results would display asynchronously, just as Worksheet users expect.  There is an "output redirected" comment, between the Groups, if an entire expanded Block is executed together, say using the menubar's `!!!` icon.

This is just one reason why I don't use Documents, and stick to Worksheets.

I see an expectedly close result in Maple 15.01, but not in Maple 16.00 onwards.

It may be possible to work around the issue by assigning UseHardwareFloats:=false and retaining Digits=10, without having to incur even more extra cost of higher that default working precision. (That still won't be as fast as hardware double precision at the key steps internally, of course.)

restart:                                      
with(Statistics):                             

r := RandomVariable(NegativeBinomial(3, 0.1)):

Mean(Sample(r, 10000)); Mean(r): evalf(%);    
                               101.792300000000

                                  27.00000000

UseHardwareFloats:=false:
Mean(Sample(r, 10000)); Mean(r): evalf(%);

                                  27.02560000

                                  27.00000000

@Mac Dude FYI, I included another kind of example (affecting BesselY, BesselK and perhaps AiryAi, AiryBi but not others it seems):

restart;                   
evalf( BesselY(0, 2/3*x) );
                          BesselY(0., 0.6666666667 x)

restart;                   
UseHardwareFloats:=true:   
evalf( BesselY(0, 2/3*x) );
Error, (in evalf/BesselY) cannot handle unevaluated name `x` in evalhf

kernelopts(version);
           Maple 2015.2, X86 64 LINUX, Nov 13 2015, Build ID 1087698

@Mac Dude I will submit an SCR (Software Change Request, ie. bug report).

Simpler example:

restart:

evalf(LambertW(3));

                                  1.049908895

restart:           

UseHardwareFloats:=true:                

evalf(LambertW(3));     
Error, invalid input: evalf/LambertW uses a 2nd argument, zz, which is missing

In addition to Thomas's suggestion, you could upload a worksheet in which the error occurs. Something else seems to have come before the problematic execution, since the floats are printed with more than default digits.

@Bendesarts I hope this is clear. When you reopen this sheet you should be able to immediately execute the last line, to show that P is the Matrix of data, without re-executing any of the earlier lines.

DT3.mw

@sarra How about...

Download aHH.mw