axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] The symbol 4 (was Re: Aldor and Axiom)


From: Ralf Hemmecke
Subject: Re: [Axiom-developer] The symbol 4 (was Re: Aldor and Axiom)
Date: Wed, 15 Feb 2006 12:00:44 +0100
User-agent: Thunderbird 1.5 (X11/20051201)

On 02/15/2006 10:25 AM, Martin Rubey wrote:
Ralf Hemmecke <address@hidden> writes:

What other kinds of integers are there? But the symbol 4 can certainly
stand for other things besides the integer 4.
Right. 4 is just a symbol consisting of three strokes. If one doesn't bring it
into a context its meaning would be totally unclear. Well, nowadays humans tend
to interpret this always as an integer, but I think several thousand years ago
that was not so clear.

However, the "guessing" of types in Axiom is tremendously useful and without
it, I probably would stop using it. Note that MuPAD does no type guessing, and
thus leaves people in fact with the expression domain by default.

Of course (!!!), type guessing may only be done by the interpreter.

I was never saying anything else. Guessing should be done only by an interpreter or maybe implemented via BNatural.

However, I wanted to stress the point that the compiler should be picky and reject everything it does not clearly understand from the context. No ambiguities allowed.

So for writing libraries the programmer is forced to state explicitly what he/she wants.

The user interface is another thing. Clearly there should be a shell around all this complicated type stuff which helps the user to solve the problem. It should, however, be transparent how the interpreter choses appropriate types or in other words. There should be a well documented algorithm how the interpreter extends the scope so that it can find appropriate functions. Maybe one needs a whole lot of (automatic) coercion theory.

Further, maybe, that affects also how libraries have to be written. For example, if you have 4 domains A, B, C, D and the following coercion functions,

   A ----> B
   |       |
   v       v
   C ----> D

and you type in d(a) in the interpreter where d: D->D and a:A then it is vital for the correctness that the above diagram is commutative otherwise it would depend on the choice the interpreter makes. Well, that says programmers should make sure that any such diagram commutes. Maybe that should become a big convention for coercion functions in Axiom.

Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]