[Axiom-developer] Re: [fricas-devel] Re: [Axiom-mail] InputForm

[Gabriel Dos Reis]

Tim Daly <address@hidden> writes:

| I've been reading this thread. It seems to me that what people are seeking
| is a symbolic algebra rather than a computer algebra system. The distinction
| is that a symbolic system manipulates input as parse trees in
| syntactic form.
| A computer algebra system manipulates input as semantic forms. It appears
| that you want to recover the syntax from the semantics, a very hard problem.

OpenAxiom has the Syntax domain for matters that are purely syntactic,

OpenAxiom's intended  of InputForm is that of expressions the semantics
of which yield computer representation of mathematical object.  In
particular, you can think of Syntax objects are pre-InputForm objects --
syntactic objects that have not yet been type checked.  So a Syntax object
is really a member of an initial algebra -- unlike InputForm or
SExpression objects. 

| This discussion came up before. At the time I wrote the beginnings of a
| symbolic front end to Axiom based on Joel Cohen's work. Joel has given
| me permission to use his books as part of the effort.

I'm familiar with his work (and his two books).  I would think that
there already exist a domain constructor, Expression, that is most
suited for the work presented in the two volumes.  The fundamental
building block is the Kernel domain constructor.  I know some people
have expressed profound dislikes of the Expression domain constructor.
But, I suspect that they would have a deeper appreciation of it after
reading Cohen's work.

The need for InputForm is not just for 'symbolic mathematics'.  A proper
support for the compilation model of the Spad language requires that any
constructor argument be coercible to InputForm.  A fact that is not --
at the moment -- enforced, but that is deeply relied upon.  See what the
devaluate functions do and the unspolem assumptions behind.

It is on my TODO list that OpenAxiom-1.3.x and up will enforce those
assumptions. 

-- Gaby