Re: [Axiom-developer] RE: More AxiomUI

[Martin Rubey]

Since I'm in a hurry, only part of an answer:

William Sit writes:
 > Martin Rubey wrote:
 > > Currently, the parser of the interpreter and the parser of the compiler are
 > > different. For example, you cannot define packages, domains or categories 
 > > in
 > > the interpreter.
 > 
 > Much I would agree with you that the difference between the two parsers is a
 > constant headache and certainly makes it harder to go from interpreter to
 > compiler, I can understand the roles and necessity of both. Being a strongly
 > typed language, to require a casual user or beginner to declare types for all
 > identifiers and to use package calls is too much. Other CAS like Maple or
 > Mathematica are not even typed. 

Of course the interpreter needs to be able to do type inference, just as it
does now -- or better :-)
 > 
 > > In fact, this is also a question of future direction, since I hope very 
 > > much
 > > that Aldor will become *the* language for Axiom.
 > 
 > What features of Aldor do you want to add to Axiom?

A clear grammar, dependent types, post-facto extensions, and all the splendid
algorithms available in the libraries distributed with aldor. (many of which
are by Manuel Bronstein)

 > > Maybe it would make sense to make the type inference as much independent 
 > > of the
 > > interpreter as possible. It seems, that quite a few type coercions are 
 > > defined
 > > for the interpreter only. Why aren't they in the algebra? One example is 
 > > the
 > > coercion from UP to POLY, I think.
 > 
 > First, a direct coercion between two domains of the same category is by
 > design, I think, not practical. Domains may differ by their mathematical
 > meaning, but even if they do not, they differ by their data structure (and
 > hence implementation). When a domain is constructed, it should not be
 > required to be aware of other domains in the same category (providing
 > coercion would), because for one thing, it may be the first. Thus such a
 > requirement would require constant updating of all older domains that in
 > principle are coercible to other "younger" ones. Note that by the same
 > reasoning, only a younger domain can be CoercibleTo an older domain, not the
 > other way round. (By making CoercibleTo go the other way would make "older"
 > become the "younger").

Part of this problem is solved (in a fine manner) by post-facto extensions,
described in the Aldor user guide.

 > Axiom handles this problem with maps. In the polynomial situation, there is
 > POLYLIFT, which allows one in the compiler programs to map one polynomial of 
 > a
 > domain into another in perhaps some other domain.  I suspect that the
 > interpreter applies this (mapping facility) to do certain "coercions" that 
 > are
 > not explicitly available (as in CoercibleTo, ConvertibleTo, RetractableTo) 
 > and
 > for some reason, the choice of these maps is not shown in )set mess bot on.