The main examples were all on .mws files.  I did not look at all the pages though.

The main examples were all on .mws files.  I did not look at all the pages though.

Just a note that there is all sorts of stuff in a 'document' which won't be picked up by that.  Frankly, I am not sure if it is possible to programmatically analyze non-worksheets.

For old-style worksheets, one can always use the Worksheet package - which, AFAIK, can only deal with mws files and not mw.  Terribly useful package, but it seems that programmatic control is not so important anymore.

Just a note that there is all sorts of stuff in a 'document' which won't be picked up by that.  Frankly, I am not sure if it is possible to programmatically analyze non-worksheets.

For old-style worksheets, one can always use the Worksheet package - which, AFAIK, can only deal with mws files and not mw.  Terribly useful package, but it seems that programmatic control is not so important anymore.

I don't have such a comparative review, but as far design ideas for future development, I have plenty.  And they are based on my knowledge of the history of CASes.  I have 2 Master's students polishing their (defended, accepted) theses who have worked on implementing parts of that, I should be able to post a link to their work soon.

As far as weak/strong types go, with so many years of experience behind us, the answer is turns out to be rather simple: strong types work realy well when you know what you're doing (i.e. there is strong theory underpinning your work), and are a huge hindrance when you don't.  In practice, this means that logic, algebra and functional programming can all be strongly typed, but analysis, geometry and imperative programming can't (yet).  Don't get me wrong: the abstract theory of analysis, geometry and even imperative programming are well established; the gap is that the theory of 'computation' over specific objects isn't.  In other words, Calculus is well-founded, but doing calculus-like computations on representations of functions (i.e. expressions) isn't.  There is no adequante 'denotational semantics' for calculus.

As far as writing a comprehensive comparison of these two systems, it's a good idea, but not something I  am likely to do 'soon'.  I have a non-trivial backlog of work that I've done that I still have to write up properly, and so I have tried quite hard to not start too many new projects before a few of the old ones are written up.

Thanks for the reminder about types and properties.  It's triggered a link in my head with stuff I am currently looking at.  My colleague Bill Farmer coined some good terminology to do with partial functions: they have an 'apparent domain' as well as an 'effective domain'.  When you say, for example, that the domain of (x:numeric) -> 1/x is 'the reals', you are really describing the apparent domain, since 0 is not in fact in the 'effective domain' (of real-valued functions).  But can, fruitfully, use 'type' for the 'apparent domain' and 'property' for 'effective domain'!  The principal reason for making a difference between them is that we can thus have a decidable type system but an undecidable property system, and still keep everyone happy.

I have seen this, and I will post something real -- later.

I made an incorrect assumption: that the "What's New" would correctly and completely describe a feature change, emphasizing its important aspects.  This seems to have been an incorrect assumption.

So, after experimenting, it seems that in fact the largest source of non-determinism was fixed too!  [I tested normal and lcoeff].  It would have been nice if "variable ordering" had been used in the description rather than (just) "set ordering".

The funny thing about this change is that it's mostly a red herring.  It is hailed as helping to deal with the non-determinism that one sees in Maple -- which it does.  However, it isn't the biggest source of non-determinism in Maple, not by far!  The biggest source (when I measured it last was that normal(1/(x-y)) randomly pulls out a -1 from the denominator [and all other such instances of random behaviour in polynomial/rational arithmetic].

It's like saying that, in the evening, you can read better when you put your glasses on.  True.  But, just maybe, turning on a light would help a lot more?

I prefer to use the 2-argument version of typematch, as it requires one less step.

`convert/ET`:=expr->subsindets(expr,
    'specfunc(anything,hypergeom)', 
    proc(f) local a,b,c,z,s:
        if typematch(f,hypergeom(
            [a::algebraic, b::algebraic],
            [c::algebraic], z::algebraic)) then 
            (1-z)^(-a)*hypergeom([a,c-b],[c],z/(z-1))     
        else f 
        end if 
    end proc);

I prefer to use the 2-argument version of typematch, as it requires one less step.

`convert/ET`:=expr->subsindets(expr,
    'specfunc(anything,hypergeom)', 
    proc(f) local a,b,c,z,s:
        if typematch(f,hypergeom(
            [a::algebraic, b::algebraic],
            [c::algebraic], z::algebraic)) then 
            (1-z)^(-a)*hypergeom([a,c-b],[c],z/(z-1))     
        else f 
        end if 
    end proc);

That implementation is certainly much clearer than the op-fuscated one.

That implementation is certainly much clearer than the op-fuscated one.

I never advocate the use of patmatch, only typematch.  They are very very different!  No speed penalty for typematch, in fact, it's probably faster than op-fuscation if you have 5+ op's in your code.

I never advocate the use of patmatch, only typematch.  They are very very different!  No speed penalty for typematch, in fact, it's probably faster than op-fuscation if you have 5+ op's in your code.

This kind of op-fuscation is exactly why 'typematch' should be used more often!