@tomleslie whoever did the deletion has a deep misunderstanding of copyright.  It does not prevent anyone from posting 'copyrighted' material - but it does prevent anyone from claiming ownership of said material.

And, of course, it displays an even deeper misunderstanding of an ages old, deep design of Maple: that its source (without comments) is available for all to inspect.  That design decision goes back to 1980, and is part of what makes Maple different than Mathematica (and what also makes Sage different than Maple).

And you are right: it should be impossible for the act of posting the output of a Maple command to be regarded as incorrect (assuming the input was not already 'incorrect').

I have personally created multiple patches to Maple (on github), for a variety of reasons.  Of course, none of my published patches print the original source code [that could indeed be perceived as incorrect -- unlike here, where that's just daft].  But part of the beauty of Maple is that this is possible at all.

I thought this was a fairly straightforward question that people would have run in to before.  Should I ask on math.stackexchange instead?

I would be quite curious as to the details that led to all these advances.  Is each example above driven by a different improvement to some part of Maple?

@acer I got used to optional parameters in OCaml.  They use different name spaces for the labels and for the name of the parameter visible in the procedure itself.  That way there are no issues with evaluation.  Rather like your % suggestion.

I now understand the details better, so I can indeed use the (massively ugly) ':-ctx'.

@Carl Love I have basically not programmed in Maple in any serious way for about 6 years, and restarted some months ago.  So it appears there's a few things I need to learn about 'modern' Maple.  [Which is excellent! ]

@Preben Alsholm Indeed.  It seems that keyword parameters work via straight substitution (as if the value was substituted in the body of the proc via subs before evaluation).  Distinctly odd design.  It seems to confuse the notion of "name space" quite thoroughly.  Which is why my hack with :-ctx works, because they belong to different name spaces [there are 3 name spaces in Maple].  And why uneval quotes didn't work.  How very odd.

The upshot of this design is still that if one routine has a keyword parameter (such as ctx), it is extremely difficult for all but advanced users to have that routine call another which happens to have a keyword parameter with that same name.

Now I need to look up what Python and R do with their keyword parameters.

@tomleslie I haven't posted to MaplePrimes in a while, so you might not be aware of who I am -- but my points score should give you a clue that I'm not a newbie...  [Take a look at my "Maple 401" post for example].

@Carl Love I have been told that this situation is not uncommon, i.e. that some threads have messages which end up disappearing.  Interesting to find out they are not "gone", just not showing up.  Hopefully this is fixeable!

When I first saw this post, it had a long discussion in it -- but most of those posts are now gone!?!?  What happened?

you are trying to sneek in proper types into Maple.  That has not happened in 34 years, I would not hold my breath!

@Preben Alsholm And(realcons, Not(infinity)) might indeed do the trick.  I am still surprised that there seems to be nothing pre-existing for this.

acer's comments are really thoughtful.  I generally agree with them, even where they seem to contradict what I said; this can easily be explained: my own comments were a little too brief to appropriately deal with the true complexity of the situation in a number of cases (think of some of my comments as a caricature of the situation, based largely on truth, but also containing obvious inaccuracies, largely put there for effect).

I will only comment on a few points, where it seems valuable.  If I don't comment, it is because I agree (including point #2 above where acer says I am being unfair to Mathematica!).  In some places, I agree wholeheartedly, in particular his point #4. 

Point #5: there are few tools for 'forgetting' because the modern way to remember (option Cache) handles this very well already.

Point #7: Mathematica seems to 'get' functional programming (which is what Reap and Sow really are, they are basic combinators from functional programming) better than Maple, which can't quite seem to shake its procedural heritage, even though it has seq/map and a few other similar primitives.  If you teach people the 'right' primitives and downplay to procedural ones, better code would be written.  It made a certain amount of sense (in 1980!) to have the Maple language be Algol/Pascal-like, since those were the prevalent ideas at the time.  But in 2011, procedural is really no longer the prevalent paradigm; in fact, even OO is slowly declining.  Functional and model-based are in high ascendancy.  Maple is actually very well placed to 'play' in both of these arenas (unlike OO, where the few features that were added to Maple to make it more OO friendly luckily never really took off).  Of course, MapleSim is as model-based as it gets (good!).  In fact, and this is quite amusing to me, the underlying denotational semantics of MapleSim, as I learned recently, are relational rather than functional [think Prolog].  At the model-based level, this makes a lot of sense.  At the 'programming' level, one generally wants more control (because of predictability).

The comment about "misplaced subservience to users' wishes for convenience" is very interesting.  In my own work, I have been thinking about this very hard.  A few of those thoughts have been published in the paper High Level Theories with Bill Farmer.  (There are slides of talks, some by Bill, some by myself, which I should also put up which expand on this theme.) The basic idea is to create a layered system, with the lowest layers being 100% aimed at highly trained, expert developers, and the highest layer being 100% aimed at a non-programmer user, with intermediate layers serving as compromises in between.  The error that acer points out is to pervert the low-level language for user convenience, as well as to pervert the user-interface with programming concepts.  I do not believe that there exists a palatable compromise that serves both audiences well, so it is better to not try.

Regarding #9 (pattern matching): completely agree.  The problem here is that there is a huge disconnect between the marketing of the feature and the reality of what you get when you program with it.  Because the innards of how pattern-matching are not known or documented, it is impossible to predict how such programs will work.  And it is very well known that pattern-matching based programs (in general, this is not specific to Mathematica, but is true of all term-rewriting) are extremely hard to control/predict/etc.  And it does generalize to other areas where the actual cost of the routine (like unapply) is not well understood.

Regarging #10 and  save on memory management time by producing less transient, collectible garbage: I would love to know how to do this.  I currently don't really know how to do this.  The theory that I know about this requires features (like 'let ... in ...' !) which Maple does not (yet?) have. 

A number of languages have a statement that looks like

let x = computation in expression

This x is an abbreviation for the result of the computation, it is not a 'variable', in the sense that it cannot be assigned to.  Such an x is immutable.  Immutable variables can be implemented much more efficiently than mutable variables; even better, they are thread-safe.

If you look at a lot of Maple programs, you'll notice that quite a lot of the assignments are in fact done only once, so that if they were done via a 'let', this would allow the interpreter to deal with them more efficiently.

What about getting some of these done?

@Alejandro Jakubi I am extremely sympathetic to your position: generally I do believe as you do, that it is the system which should adapt to the user, not the other way around. 

But acer's answer points out the exact underlying issue: there is essentially no body of literature on mixing symbolic and numeric 'properly', and exhibits a number of places where Maple is quite inconsistent because of this.  In the face of this huge unknown, I have reverted from my usual position to one which relies on users knowing that symbolics and numerics should not (currently) be mixed if predictable results are needed.