axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Re: Axiom interactive input syntax


From: Bertfried Fauser
Subject: Re: [Axiom-developer] Re: Axiom interactive input syntax
Date: Wed, 10 Dec 2003 12:15:24 +0100 (CET)

On Wed, 10 Dec 2003, David MENTRE wrote:

Dear Bill and David,

a very interesting discussion. As a prototype of an ignorant user, I would
be satisfied by a clear statement of what kind of input is necessary in
what interface. Just to tp`ype a few ' _' signs in a comand line session
is no trouble. But I hadn't found no hint that the syntax is different.
That was the most confusing point and that is most easily cured I think.


> >> (2) would be, at the same time, a unique, well defined and
> >> correct type inference.
> >
> > That is certainly the hard part! <grin>
>
> A hard part, but *maybe* not the most difficult one (if record-like type
> inference suits Axiom needs).
>
> > That is interesting but compared to what we were discussing
> > originally about unifying the Axiom interactive input language
> > syntax with the compiler language syntax - this is what I
> > would call *very* ambitious.
>
> Yes. :) Never let a computer scientist try to make some science. :)

Why NOT? Or was all of AXIOMS algebra coded by mathematicians? I doubt
it...

However, I do *not* see any possibility to detect automatically the type
of a data structure. Hence AXIOM will for sure fail in some cases to
compile a correct function if no type specification is given.
Eg: A list of intergers could be a list of bases in a Grassmann algebra
*or* a partition *or* a .... if I would like to add these, I need
'+GRASS' and '+PART' and ... and AXIOM cannot decide this. In this sense,
a 'soft' user interface would need to be even inquisitive about the user
and ask interactively about data types if ther eis more than one known
choice for a libary function.
        Even worse if you define functions, which might implement new such
possibilities and the compiler would even need to *understand* the
legality of a proceedure on a certain data structure. That's even a task
difficult for mathematicians.

What would be of utmost help to me would be a very very good graphical
type brouser. Indeed even with the large amount of series one is
tourtored. Furthermore its not so easy to convert types and there should
be when ever possible a cast operator to perform such changes. At least in
such a direction to the more general ttype, hence loosing information.
        Eg a Euclidean ring is also a ring and if Euclidean is not
necesary or even disturbe then it might be dropped. IF later the property
Euclidean of that data is needed, AXIOM is lost, since checking for such a
property might be impossible without further information or user help.
        A brouser could help to keep trak of system wide known typse and
might come up with a dependence structure (like the algebra dependencies?)

cheers
BF.

% |   | PD Dr Bertfried Fauser    Fachbereich Physik    Fach M 678  |
%  \ /  Universit"at Konstanz     78457 Konstanz        Germany     |
% (mul) Phone : +49 7531 693491   FAX : +49 7531 88-4864 or 4266 (comul)
%   |   E-mail: address@hidden                   / \
%   |   URL   : http://clifford.physik.uni-konstanz.de/~fauser    |   |





reply via email to

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