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

Or why would anyone care about a partial evaluator in Maple?  I see 3 reasons:

1. Efficient Genericity: one can write very general programs that take all sorts of funky parameters, but not pay the cost of the extra generality when these programs are used with fixed parameters.  This is what the QuickSort example shows.  This also applies to GenericLinearAlgebra [see Appendix B of the journal paper] (and in fact, to LinearAlgebra in general), most generators in Statistics, and many many routines which are extremely general but are used in very specific ways in any given piece of code.  The Domains package is probably the most obvious 'extreme' here.
2. Complete symbolic answers, which we dubbed Residual Theorems.  Basically one can take code which is meant to operate on exact inputs, feed it symbolic inputs, and as a result (fully automatically!) get the full case breakdown.  In other words, where Maple currently (invisibly, sigh) chooses to give a generic answer, we can automatically generate the full correct answer (as a residual program).  See the example with degree or the mock integrator (p.32-33 of the journal paper).
3. Source-to-source optimization.  A partial evaluator can be understood to be a very aggressive 'constant propagator' and 'inliner' all rolled into one.  More generally, it is an 'information propagator' which takes all known information available at a program point and uses it to 'simplify' the rest of a given program.  In the tests supplied with the source code, see for example the specialization of the code generator for the Weierstrass functions (all 4).

Maple's own library code could benefit a lot from #1 and #3.

The project now has a proper web site, from which you can see some examples, as well as simple usage documentation.  The publications page contains links to more papers too.

On the official download page, the source-only package offers both a .tar.gz and a .zip.

It was really slow for me too the last few days, but it's fine now.  My guess is that there is some part of the web software which has a slow memory leak, so things need rebooting once in a while.  Even leaking a single byte per page served will kill a web server in a matter of days.

More precisely, I should say that what you are asking for is quite possibly in the realm of optimizations that one can option via partial evaluation, but I am not sure.

Or perhaps it would be better to say that with the usual ideas of partial evaluation, which boils down to "very very aggressive constant propagation" (where most of the gains come from propagating known functions called on partially static input), probably would not be able to 'invent' such optimizations.  If, however, they are already present in the code in 'special cases', then partial evaluation might well propagate that information 'up' to the more general case.  But this is rather subtle, so I would have to look at things in detail to give you more than this off-the-cuff answer.

If PE isn't enough, then supercompilation probably is.  With that, you can do some amazing things like verify laws that code should satisfy and other cool stuff.  I have not looked at implementing that at all.

I/we will provide all of these things, soon.  I just wanted to send off the announcement sooner rather than later now that everything is properly uploaded into SourceForge's subversion repository for our project. 

Unfortunately, 'soon' probably means early next week.

The simplest way to think of a partial evaluator is as a source-to-source (ie Maple to Maple) 'super optimizer'.  It runs, at "compile time" everything that can be done 'now', without knowing the values of all the parameters.  In the context of Maple and symbolic computation, that is frequently a lot.

I was indeed not precise enough.

I was indeed not precise enough.

cmaple works, sort-of.  I have this new machine, fast and with lots of memory.

cmaple takes 5.5 seconds to start.  It should start in the blink of an eye.  I have no idea what it's doing to take so much time to start.  I have no idea what to check to debug this.

cmaple works, sort-of.  I have this new machine, fast and with lots of memory.

cmaple takes 5.5 seconds to start.  It should start in the blink of an eye.  I have no idea what it's doing to take so much time to start.  I have no idea what to check to debug this.

Now I can't even uninstall Maple.  Whether I try via Windows or via the Maplesoft-provided uninstaller, in both cases the uninstaller just quits right away without doing anything.  Now I am stuck with a Maple which doesn't work that I can't get rid of.

Now I can't even uninstall Maple.  Whether I try via Windows or via the Maplesoft-provided uninstaller, in both cases the uninstaller just quits right away without doing anything.  Now I am stuck with a Maple which doesn't work that I can't get rid of.

Wolfram Alpha relies on an obvious observation: programming languages that are really good for symbolic computation are good for much more than mathematics (at which they excel), but at all sorts of other tasks as well.  As if the LISP and PROLOG hackers haven't known that for many decades now!  The only people who don't know that are those stuck with "mainstream" languages as their workhorse - you know, C, C++, Java and so on. 

Stephen Wolfram is a genius at Marketing though.  So I am sure he will get a huge amount of press over this, whether it's good or not.  Having said that, he has done this before: he got a huge amount of press (and sales) of Mathematica back when it was really really bad, and 10 years later the product is actually pretty good. 

On the other hand, this is starting to intrude on Google's turf.  I wish him luck with that!

There isn't even a technical reason for it - Classic ran on 64 bits (on Dec/Compaq/HP Alphas) and clearly it works on Windows, so the principal hurdles for such a port have been cleared long ago.

I guess I'll have to uninstall this version and install the 32 bit version instead -- hopefully that works?!

There isn't even a technical reason for it - Classic ran on 64 bits (on Dec/Compaq/HP Alphas) and clearly it works on Windows, so the principal hurdles for such a port have been cleared long ago.

I guess I'll have to uninstall this version and install the 32 bit version instead -- hopefully that works?!