&* and &^ are too special to Maple, it is too dangerous to use them.  Same with &where.  Those 3, at least, should be protected. 

This would be typical of most Maple rules... you know it's a rule because it has exceptions...

Of all of these behaviours, that is the one that makes most sense to me.  Maple 9 seems to be broken in 2 different ways on this 'test'.

The funny thing is, there is a non-trivial chance that I was the one who 'broke' Maple 6 in this particular way (I did a major cleanup of the protected names around that time, and I know that I made a couple of mistakes while doing that).  I would be curious to know if it was me -- someone from Maplesoft [or with access to the repository] can probably find out. 

These have been 'known' to mod since (at least) Maple 4.*, ie the mid 80s!  It may go back further, but I don't have access to that anymore.  I don't know if something changed in evalhf 'recently' with respect to those functions though.

&* and &^ are the only operators known to `mod` too.  So it seems that these are somehow special to Maple.  And 'special' usually means 'gives strange behaviour under stress'.

Most EULAs (End-User License Agreements) for software basically say that the company makes no warranty whatsoever about the fitness of the product for any task.  Furthermore, the so-called 'lemon laws' (in the US as well as in other countries) generally have explicit exceptions for software.

It is we, the consumers, who are stupid enough to purchase any software under those conditions.

At some point, you get so aggravated that you do something about it.  First, you might complain loudly.  Then, you might not upgrade (and tell many not to either) since you don't feel the upgrade is worth the money.  Eventually, you switch products (if there is a competitor that seems worth it).

Not upgrading is easy enough to do - and is real lost $$$ to a company.  Switching is much harder.  This 'lock in' is what allows makers of software to continue shipping product riddled with bugs and yet still make money.

It should be clear from the above that Maple's is function deals with continuity of expressions, not functions.  Mathematically, that might seem very weird indeed, but that's because Maple works best with representations of functions (ie expressions) rather than functions themselves.

Mathematicians do not make much of a difference between these two concepts, but in a computerized context, it makes a huge difference.

It should be clear from the above that Maple's is function deals with continuity of expressions, not functions.  Mathematically, that might seem very weird indeed, but that's because Maple works best with representations of functions (ie expressions) rather than functions themselves.

Mathematicians do not make much of a difference between these two concepts, but in a computerized context, it makes a huge difference.

You will not find sellers of commercial math software jumping on that particular bandwagon anytime soon!  Sure, some open source software has their bug database 'public'.  But how many closed-source, for-profit software companies do you know who have such an enlightened policy?

Personally, I tend to use a table-of-functions (a generalization of Joe's answer) when I need a 'switch' statement in Maple.  If you provide us with a somewhat more realistic example, I am sure we could come up with a nice way to do it.  I have had rather good success with these tables-of-functions.

Personally, I tend to use a table-of-functions (a generalization of Joe's answer) when I need a 'switch' statement in Maple.  If you provide us with a somewhat more realistic example, I am sure we could come up with a nice way to do it.  I have had rather good success with these tables-of-functions.

The reason, AFAIK, that goto was never documented was the collective horror that it existed at all (it was not implemented by Maplesoft).  Maple has enough mis-features as it is, there is no need to encourage users to make their code worse still.

The reason, AFAIK, that goto was never documented was the collective horror that it existed at all (it was not implemented by Maplesoft).  Maple has enough mis-features as it is, there is no need to encourage users to make their code worse still.

It seems to me that the help system is severely broken in Maple 12 Classic [from your reports and several others that I have seen].  Have you filed these as SCRs?  That is the best way to insure they are 'in the system'.

Since Classic is not really maintained anymore, I wonder what is considered an 'unacceptable' bug.  All software products have certain functionality deemed so essential that any problems with it would be considered a 'showstopper' to shipping the product to (paying) customers.  Since Classic is a 'shipping product', there must be such a treshold?

I know that my posts are read by many people at Maplesoft (from comments I have received in person). Oftentimes, they even agree with me -- a statement which is all too often followed by a deep sigh.

I am not foolish enough to think that anyone is ``listening'', nor would I actually want that.  What I want is for people (including Maplesoft employees) to critically evaluate what is current practice versus what I say.  If this critical evaluation causes people to re-evaluate their position, I am glad, that is success.  Note that if they decide not to make any changes, because their re-evaluation concluded that the current position is, given all available data, better than the other options, I am still happy.  I want people to question the status quo, so that they think about the underlying assumptions.

I sometimes take positions which I know are unrealistic, for the express purpose of getting people to think.