(Resent as it didn't appear in my maxima mailing list - apologies if you get
this twice)
On Wednesday 13 October 2004 18:39, Richard Fateman wrote:
> Of course this perspective is from the computer algebra system. If what
> you are building
> is primarily a GUI for (say) maxima, tex, matlab, GAP, web browsers,
> search engines, ... etc
> and maxima is just a specialized client for a small percentage of users,
> then the GUI
> arguably should be the boss. The usual downside of this is that some
> things are either
> impossible or very very hard to do. (The lisp code shows very
> explicitly what expressions
> are subexpressions of others. Do we really need to re-parse? )
Yes, this is a GUI, and nothing but a GUI, a utility to improve the UI to
Maxima and its ilk. Yes, some things may be very hard without access to
Maxima's internal representation. As soon as you start creating new Lisp
functions etc., Kayali will struggle, but if there is a need then effort can
be invested.
>1. the internal lisp version as a text string. Â e.g. Â ((MPLUS SIMP) $X
>$Y)
> >The second good news is that it is not written in Lisp, so that the
> >interaction to the maxima kernel is somewhat more bound to a clear
> > interface.
>
> This is questionable, given that the front end has a duplicate parser
> for the macsyma input language,
> written in python.
>
I didn't realise that Maxima's internal parse tree was available in text
form. This is useful to know.
Kayali's parser is, for all intents and purposes, a grammar definition text
file. It is easily changed or extended, no coding is involved.
The benefit of using my own parser is that it can be modified to use other
back-end tools that also understand textual algebraic expressions of the
form 3*x^7 or similar. This makes Kayali extensible, for instance, to use
more numerically-oriented engines such as Octave.
Abdulhaq