[Axiom-developer] .spad, .input, .as and autocoercion

[Ralf Hemmecke]

On 08/16/2007 12:11 PM, William Sit wrote:
> Martin Rubey wrote:
>
> > I have used Aldor, SPAD, the Aldor interpreter and the axiom 
> > interpreter quite intensively, and found the combination Aldor + 
> > axiom interpreter formidable.
> >
> > What I found most impressive is that the axiom interpreter is 
> > designed well enough to work seamlessly with new packages.
>
> Since you do find the axiom interpreter helpful and indeed getting 
> the types right (your examples are not particularly impressive to me 
> because the names and signatures are quite unique and only the 
> arguments need be matched), why aren't you and Ralf in favor of 
> improving the compiler so that the compiler can be equally helpful?

Because I believe we will end up in something like Maple or Mathematica.
I constantly hear people complain that they don't understand what
Mathematica is actually doing internally.

> Why should the human programmer be forced to manually perform what 
> the interpreter is doing so well (and most likely can be even 
> improved)?

You say it. The interpretation of your source code depends on the
capabilities of the "interpreter". That is like saying

simplify(someexpression)

in Maple which doen't simplify anything in Maple6 but does something in
Maple11.

> Currently, to translate from interpreter language to compiler
> language, one needs a combination of ")show," ")display," ")set mess
> bottom on," ")set message auto on," and hyperdoc searches to identify
> packages and coercions. This process is repeated every time there is
> a compiler complaint. This is time that could be spent for
> documentation instead.

If you simply make your experimental code into something that SPAD
understands than you are missing the *design* phase.

> Thu, 16 Aug 2007 01:35:08 +0200 Ralf Hemmecke wrote:

> > Interpreter and compiler language are identical and identically 
> > strict. No auto-coercions.
>
> > You cannot expect that it will be painless to implement library 
> > code from fuzzy experimental code.

> Why not? All code is experimental until it is final and frozen.

I believe that it is good to have a system that let's you experiment
with objects and lets you invent new algorithms. But once you have an
idea how that should actually work you should make the input/output
specification clear. That for example will most probably rule out the
use of "Expression Integer" in library code. There will be most
certainly be domains that are more specific for the implementation of
the algorithm that you have just invented.

> Documentation is constantly being added and revised. I don't consider
>  documentation "pain," because it is necessary. I do consider
> spending time to rewrite interpreter code into compiler code a waste
> of time and therefore "pain".

Being also a mathematician, I clearly understand your point. But
Computer Algebra deals with constructive mathematics. And there is a lot
more to tell a stupid computer. If some day we arrive at a system that
can translate fuzzy experimental code into nicely specified and
efficient library code, then I am on your side. But this is probably a
big research topic.

> (Compare this with the pain associated with style changes for
> bibliography items when bibtex is not used.) As long as the
> interpreter language (what you call experimental language) and the
> compiler (or library) language are one and the same, the pain level
> would be reduced substantially (to zero if the two are 100%
> compatible).  Of course, we should not let the compiler "guess" like
> the interpreter currently does, but the compiler can "help" to
> provide a set of choices and recommended selections (much like a
> spell-checker presents a list of alternatives to let the writer
> select or decline).

The Aldor compiler sometimes tries to help you in such a way. There are
messages like

No function foo: () -> Integer is available but could be used if
imported from SomeFooType.

I certainly have nothing against the compiler listing all the options at
the place of failure. I know what a pain it was to rewrite .input files
into .spad files. That was one of the reasons I stopped writing .input
files in Axiom. Or I should better say, I stopped developing programs
using .input files.

[...]

> The three incompatibles (interpreter, Spad compiler, Aldor compiler)
> are, I believe, the main reasons why the commercial version did not
> receive wider popularity. This triad of languages becomes confusing
> to most users, old or new.

I very much agree. But I still don't want autocoercion. The user 
interface (i.e. type guessing and such -- which corresponds to BNatural) 
should be programmed in a library and should not be part of the 
Aldor/SPAD language.

> But hacking is only a good skill to find bugs or get a program 
> working, not essential, and indeed, may even be detrimental, to write
> readable programs. Hacked code distracts and hides the natural flow 
> of mathematical or computational ideas. It would make documentation 
> "extra painful" to write, and thus often, not written.

> The question is: do we want Axiom/Aldor to remain the havens for 
> hackers or make it palatable to general researchers, whose hacking 
> skills and stamina may be, on average, much less?

I understand your point. And it must be addressed that the ordinary 
mathematician is usually not very knowledgable in programming. But maybe 
that will change in the future. At least a bit. Languages will get 
better and closer to mathematics and people will be more knowledgable 
about computer programming.

Ralf