> I agree. There are at least these representations available:
> 1. the internal lisp version as a text string. e.g. ((MPLUS SIMP) $X
> $Y) or as a data structure if you are still in lisp.
> 2. the formatted version, also in lisp, that changes stuff like
> a*b^(-1) into a/b for pre-display consideration
> 3. the layout version (which does line breaking and knows how long names
> are)
> 4. the text string as a command, e.g. X+Y;
> 5. the text string as a LaTex command.
The way I see this list is, that it shows that display and contents is already
mixed in the core project. I don't require an IDL specification of the
interface to a maxima kernel, but there should be at least one communication
layer that satisfies the following points:
- Input and output language are the same, i.e. you can take (meaningful) parts
of the output and feed them as input again without additional parsing.
- Output is fully simplified (in the pre-display sense above). You need to
know something about math to simplify an expression, so this task belongs to
the math kernel.
- No formatting is done on the output. In particular, line breaking is
business of a view and definitely should be hidden behind a view's compositor
strategy pattern. From the list above, 4. seems to be the closest match, and
3. and 5. are for sure the wrong choices.
> Mathematica, and the commercial Macsyma front end appear to use #4.
> TexMacs appears to use #5.
This is why you can't take parts of a computation result as part of your next
input line via mouse actions.
> 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? )
A CAS GUI is a perfect example where a Model-View-Controller design applies.
As this involves dedicated responsibilities, I don't understand the meaning
of "the GUI should be the boss". But there is really no need to discuss
line-breaking, layout markup or the underlying window toolkit in the first
place:
Line-breaking algorithm and layout markup are properties of views. You may
even switch between a MathML-view and a LaTeX-view at runtime, e.g. using
LaTex for a PrintView and MathML for a ScreenDisplayView.
You can change the underlying window system afterwards by using abstract
factory and bridge patterns, or simply by using exiting frameworks that do so
(e.g. wxPython in this case).
What really needs to be discussed is the model! For a notebook style CAS GUI
this would be the internal representation of a notebook document. Since this
inevitable includes an internal representation of messages from an to the
CAS, you can restart reading this email from the beginning.
Regards,
Michael