I think the main reason is indeed historical.  It is surprising that this mis-feature of AND was ported to `and` though.  That seems like a pure mistake. 

That AND is binary is one of those early design decisions that really ought to have been fixed long ago (all commutative-associative operators should be n-ary).  Backwards compatibility is probably, again, the excuse for not fixing it. Although, in this case, I would be honestly surprised if there was any good code (other than kernel code) that broke because of such a change!

You will notice that, in fact, there are few standard "expression manipulation primitives" outside the very polymorphic usual suspects of op, subsop, select etc. They 'exist', but as inline code in hundreds of places all over Maple's library, in tens of subtle variations.  The usual reason given for this is 'efficiency'.  I used to be convinced by that argument, but I have started to rethink my position.

You will notice that, in fact, there are few standard "expression manipulation primitives" outside the very polymorphic usual suspects of op, subsop, select etc. They 'exist', but as inline code in hundreds of places all over Maple's library, in tens of subtle variations.  The usual reason given for this is 'efficiency'.  I used to be convinced by that argument, but I have started to rethink my position.

One would indeed think that that is it.

However the problem is that sometimes you want to consider some expressions to be "algebraic" even though it is made up of non-algebraic pieces!  For example, consider int(f(x),x=0..1).  That is not algebraic in your sense, as neither type `=` nor `..` are algebraic.  So the problem is some data representations for what we think of as algebraic objects are not made up of pieces which are considered 'algebraic' (nor should they be!). 

Note that the only exception(s) to your code are all of the same shape: they are a 'mathematical function' (so of surface type function) where some additional data is represented non-algebraically.  For those 'mathematical functions', the best thing is to not recurse into them, at least if you wish DeeplyAlgebraic to correspond to something more intuitive.

One would indeed think that that is it.

However the problem is that sometimes you want to consider some expressions to be "algebraic" even though it is made up of non-algebraic pieces!  For example, consider int(f(x),x=0..1).  That is not algebraic in your sense, as neither type `=` nor `..` are algebraic.  So the problem is some data representations for what we think of as algebraic objects are not made up of pieces which are considered 'algebraic' (nor should they be!). 

Note that the only exception(s) to your code are all of the same shape: they are a 'mathematical function' (so of surface type function) where some additional data is represented non-algebraically.  For those 'mathematical functions', the best thing is to not recurse into them, at least if you wish DeeplyAlgebraic to correspond to something more intuitive.

This 'trick' is very old, and used to be pervasive back in the days where readlib was necessary.  Luckily, readlib was made obsolete, and yet now this trick pops up again!

I thought that that was exactly why ModuleLoad was created for. This kind of initialization really ought to be done at load-time of the StringTools module, rather than through evil side-effects. There is a downside to ModuleLoad: all routines, whether they are used or not, would get loaded if any are. But that should be fixeable too. The 'persistent store' mechanism should be able to deal with that too! Creating a thunk that is only resolved upon first read (for the 2nd parameter to the call_external) should be relatively simple.

Ah yes, those were the glory days.  Maple would compute just fine, with an interestingly usable user-interface based on MPW -- all in 1 Megs of memory!

It is comforting that ?extension agrees with me ;-)

Anyways, there are lots of routines that use that hack, but not all are documented.  Certainly diff, expand, convert and evalf; but also combine, simplify, type, limit, series, discont, is, print, latex, D, abs, signum, evalc, and evalr all support this form of extensibility.  And surely I am missing some.

The old extension mechanism by name-formation is a horrible hack which should be deprecated as soon as possible.  It is silly and dangerous.  It is a piece of history which should be fully in Maple's past instead of still in its present.  If Tools packages are the current preferred way, then indeed that should be done across the board.

There are actual images at the other end of that link.  What we don't understand is why all of them appear the same?  If we explicitly view the images, they load fine.  Very strange.

In Maple lingo (although I don't know if it appears in the documentation anywhere!), type algebraic is a surface type.  That means that it only checks the outermost 'type' present in the object at hand to make a decision.  This makes it extremely fast, but also rather counter-intuitive (as John found out the hard way).  So much so that there is a fair bit of code in Maple's own library which is not so well protected by type-checks because they use 'algebraic' where they really mean "deep algebraic".

Now, as far as I know, Maple still does not have a type for a "deep algebraic"!  It has some 'deep' types - polynom and ratpoly come to mind. 

In Maple lingo (although I don't know if it appears in the documentation anywhere!), type algebraic is a surface type.  That means that it only checks the outermost 'type' present in the object at hand to make a decision.  This makes it extremely fast, but also rather counter-intuitive (as John found out the hard way).  So much so that there is a fair bit of code in Maple's own library which is not so well protected by type-checks because they use 'algebraic' where they really mean "deep algebraic".

Now, as far as I know, Maple still does not have a type for a "deep algebraic"!  It has some 'deep' types - polynom and ratpoly come to mind. 

I also use Firefox, and I get exactly the same behaviour as you do.  A little Googling found some information on the Firefox property permissions.default.image.  I have not mucked with that, so in theory it should work!  Strange.

Maple already had an ASCII pretty-printer from Maple 4.2 [when ?updates,v42 documents it was improved].  Clearly, the pretty-printer pre-dates that.

The 'latex' command existed at least in 1992.

In Maple V Release 2 under Windows, what you would have seen is probably my port (from the X11 version of Maple) of Tim Tyhurst's pretty-printer.  That was a fair bit of work, as the underlying font metrics in Windows work quite differently than under X11.  Tim's was already Maple's 3rd pretty-printer!  He based his work on what David Clark had done, who had written his "in anger" at how bad Maple's first pretty-printer was.  As far as I know, the pretty-printer in Standard is the 6th that Maplesoft has written, where Tim Tyhurst had written the 4th (part of the equation editor in Classic -- few people know it has one!).  The 5th was never released.  Maplesoft owns the rights to yet another pretty-printer, which used to be used in MapleNet, but I am informed that it no longer is.  [Which is too bad, as I think it produced better results than the curren one!].

[My guess as to] why assume and many other things are not discussed in this interview: to have done so would have made it 300 pages instead of the (already long) 82 pages it is.  Gaston (and his ex-student Trudy Weibel) were indeed the original designers of assume, with Gaston (re)implementing the whole facility.  But Gaston also wrote many other significant parts of Maple - he was extremely productive, and had a flair for knowing which facility was core to the rest of the system.  He often did not implement the pieces of Maple that were most user-visible, but he very frequently implemented those pieces which were foundational for much of the system.  So his design decisions mattered a lot.

You are absolutely right that the implementation of assume as it currently stands is a patch on top of Maple.  Based on what was available at that time, it was certainly a "local optimum" implementation.  Even Gaston has stated (later) that if attributes had been available (something he also implemented), maybe that would have been a viable implementation mechanism.  A new system, implemented from scratch but with these issues in the original requirements would indeed result in a different design.  What that design would be, I am not sure if anyone has really thought it through, since it clearly would never happen.  [The end result would not be 'Maple' anymore].