Re: [Axiom-developer] A Canonical Axiom GUI

[Kai Kaminski]

C Y <address@hidden> writes:

> Hey Kai!  We never seem to overlap on IRC, do we? ;-)  Sorry about that
> - I need xchat to make a noise when someone sends a message to me. 
> Hmm...
:-)

> --- Kai Kaminski <address@hidden> wrote:
>
>> The tool doesn't change, only the GUI. Do you know any other
>> successful language that has a canonical GUI? Certainly not C/C++,
>> Java, Smalltalk, Lisp, Python, Ruby, Fortran.
>
> Are you saying you regard Axiom as a language?
Axiom isn't a language perse, but it incorporates Spad/Aldor, which is
one (two actually) and offers an interpreter. How is that different
from Lisp, Haskell, ML or any other programming language that offers
an interactive environment?

Wouldn't you expect the average user of Axiom to write at least little
programs/libraries?

>> I certainly hope that implementing the two examples you give doesn't
>> require one to be an Axiom expert. Why do you assume that 3rd parties
>> are not interested in developing powerful GUIs? Non of the free Lisp
>> implementations has an IDE and most people are using Slime, which is
>> just great (even though not nearly perfect).
>
> SLIME is quite good, but I'm not sure the cases are comparable.  If you
> look around, I think you will find that there are few to no open source
> mathematical environments that approach Mathematica's notebook
> interface.  Texmacs probably comes the closest of any I am familiar
> with, but it is not tightly integrated with the mathematical
> environment.  Some, like wxMaxima, are nice and quite functional but I
> think we should strive to have a GUI the way Axiom strives to be a CAS
> - to be a solution so good that using it is a no-brainer.
You seem to suggest that we are better suited to built a powerful,
complex GUI than the community at large. I don't believe that.

I don't know why TeXmacs isn't as tightly integrated with any
mathematical environment as you'd wish. I *do* know, though, that it
would be fairly hard to integrate it closely with Axiom, because Axiom
is somewhat 'unfriendly' to programs. If anyone feels that this claim
should be substantiated I'll happily give a few examples.

>  Study all
> existing solutions, find the best features of them all, research it
> (there is existing work on the topic that is quite academic in nature),
> and then design the interface using literate programming techniques. 
> To me Lisp makes sense as the language of the GUI because that is also
> the foundational language Axiom is written in.
I disagree with this on several counts. First of all this looks like
the waterfall model to me. Figure out what we want, implement it, be
happy. The problem is that we don't even know what we want, and we'll
never figure that out without writing some GUI code.

Why does a GUI need literate programming? Correctness in the GUI isn't
nearly as important as in the mathematical core. Besides, literate
programming is an investment in the future. GUI code often doesn't
have much of a future, since things change rapidly. Especially the
first few GUI attempts will be so bad that people will throw them
away, anyway. That shouldn't stop anyone from using LP if so inclined.

I don't understand the connection between the implementation languages
of Axiom and (one of) its GUIs at all. The only good thing that would
come out of writing the GUI in Lisp in that regard is that the GUI
could run in the same Lisp image as Axiom (that would require
multi-threading, by the way, unless you're prepared to let your GUI
stall for hours at a time). That would spare us the burden of defining
a network protocol and we might even do without a proper API to the
core by just letting the GUI code dig around in the bowels of Axiom.
While that is tempting I strongly believe that it is important to
make building GUIs in any language as easy as possible.

>> Why can't you provide this experience without a canonical GUI? Linux
>> doesn't have a canonical GUI, it doesn't even have any standard
>> software.
>
> There are arguments that it suffers because of this, particularly from
> the standpoint of those looking to offer commercial software on Linux. 
> I admit I don't know, since the only way to find out is to try, but I
> suspect that developing a top notch CAS GUI will require those familiar
> with Axiom itself to be deeply involved in the process.
Someone who isn't at least somewhat familiar with Axiom or CAS in
general probably wouldn't attempt to write a GUI for it (oh, the
irony). The only things that require deep Axiom knowledge are the
specification and implementation of the Axiom/GUI protocol. Writing a
top notch GUI requires GUI design skills and an end user perspective.

Besides I never argued that Axiom's core developers shouldn't be
involved with the development of one or more GUIs. I'm not convinced
though, that they'll produce the best GUI possible. Furthermore I'm
confident that they have more important things to do. To rephrase that
argument: Many people can do GUI development, but only very few can
work on Axiom's internals. It sure isn't a good idea then, to have the
Axiom experts hacking on the GUI.

>> That's why mere mortals don't just download the kernel, but
>> instead install Ubuntu, or whatever the latest hip Linux distribution
>> is (I don't mean to disparage Ubuntu, as far as I know it's a fine
>> system).
>
> Agreed.  But it does result in effort being diffused over many
> distributions and many parallel efforts.  This is the nature of open
> source and definitely allows for new features to be tried, so I don't
> decry it - but I hope that new and advanced features of mathematical
> GUIs could be incorporated into a unified, powerful environment for
> Axiom instead of having the user forced to sacrifice one feature or
> another depending on their choice of GUI.  (Minimalistic interfaces
> aside, of course - there the whole point is to have fewer features.)  
Parallel efforts are great! Suppose there was one true Linux. Do you
believe that all the people who work on specific distributions now
would then instead work on the one true version? Also what if there
are two really cool features which you can't support at the same time?

>> > 1.  I think a default GUI for Axiom would be a Very Good Thing
>>
>> As I said, I'm not convinced.
>
> No worries.  There is plenty of room here for differing opinions :-).
Don't kid yourself. There's barely enough room for mine. ;-)

>> > 2.  The project is not yet a a point where this should be a major
>> > focus for the project as a whole.
>>
>> That depends on what you mean. I believe the most important thing is
>> to make it developer friendly. In particular we must be able to use
>> all the open source Lisp libraries that are available. Also, writing
>> tools (especially GUIs) for Axiom should be easy.
>
> Right.  What I ment was we shouldn't be (as a project) worrying about
> GUI design when we can't run on ANSI lisp yet.
Exactly. By making GUI development easy other people who can't or
don't want to work on the more pressing problems (ANSIfication,
Spad/Aldor, elimination of BOOT [that one's for you, Bill ;-)] etc)
can start working on GUIs. Later, when the more imminent problems have
been solved, we can look at the existing GUIs and figure out where to
go from there. Why should GUI development have to wait until
everything else has been taken care of?

>> > 4.  Code counts more than opinions, so I'll be quiet until I have
>> > more of the former ;-).
>
>> I'm not so sure about that. How can anyone start coding if there is
>> no consent of what the core of Axiom is and what features it should
>> offer to GUIs?
>
> Well, that's a bit different.  What we should expose to GUIs and how is
> probably somewhat separate from how the GUIs use that information.  The
> latter is usually where most of the trouble comes in :-).
It is indeed very different. Of course, the former should be guided by
the latter. Since we don't really know what a great GUI should look
like, we'll have to take some educated guesses and then wait for
feedback.

>> Finally I'd be interested in how we could get such a canonical GUI. I
>> see two ways, each of which has its fair share of problems.
>> 
>> 1) We discuss what features the GUI should have and what
>> modifications to Axiom's core are necessary. Then some poor soul
>> starts coding and after some time (probably measured in years) we
>> end up with the canonical GUI as the Axiom gods ordered it (that's
>> us).
>
> :-).  I'm beginning to think that most really high quality software
> does take years.  TeX, Axiom, BrlCAD...
Sure. Most great software is the result of evolution, though. Another
argument why we shouldn't be too picky about the quality of early GUI
code. This in turn means that the GUI code shouldn't live in Axiom's
main branch, or in any Axiom branch at all.

>> What if it fails for whatever reason? What if some third party
>> builds a GUI that is much more attractive to users than the
>> canonical one? Look at GNU Hurd and Linux. I seem to remember that
>> Hurd is the 'canonical' GNU OS. Does anyone care?
>
> Well, if what I have heard about Lisp holds true in GUI programming it
> should be fairly hard for anybody to create a feature we can't
> incorporate one way or another ;-).  The idea of a literate GUI
> program
That doesn't imply that it's a good idea. Besides you have to consider
library issues. Despite Lisp's greatness as a language, there isn't
good support for native Cocoa (Mac) user interfaces. In fact it's not
even clear that there ever will be. On Windows there is an effort for
a native GUI library, but it's still in alpha as far as I know (google
for 'graphics-forms'). Even if that succeeds you might be better off
with Visual Basic (as sad as that is).

> should be that it is first about ideas, and second about the
> implementation of those ideas.  If we do it right and cover most of the
> key elements of such programs from the beginning (and there are many
> similar elements) then further extensions of the core functionality
> should be managable.  From my standpoint, the key problems are:
I claim that you won't have the right idea without actually writing
code. Some features look great in theory, but don't work out in
practice. It is notoriously hard to predict these things. Hence the
'design first - code later' method will break down.

> 1.  2-D interactive mathematical display and formatting, particularly
> line breaking and font interactions.  Probably the hardest single part.
This is of interest to other people as well
(eg. cl-typesetting). Thus it should be done in a separate general
purpose library (eg. cl-typesetting).

> 2.  2 and 3-D plotting, interactive manipulation, etc.  IZIC has done
> some work that I like, and VTK is also very nice - adapting those ideas
> and some work that has been done on how to do high quality mathematical
> plotting is probably the second hardest part, or even hardest if we
> also cover the core algorithms for graphical display and manipulation
> ourselves.
That's been done for other languages already. It would be cool to have
a flexible plotting library in Lisp. But it's a waste of time write
now. There are good offerings in other languages, so just use
them. The Python Matplotlib source is about 30,000 lines, if I recall
correctly. Do you really want to recreate that effort for the sake of
purity? I don't.

> 3.  IO in various formats.  TeX, LaTeX, openmath, MathML, a file
> storage format for Axiom notebooks, Word's equation editor and doc
> format, pdf (particularly the interesting new trick of embedding movies
> and objects you can interact with).  Communications protocals
> between
I reckon that most of this should be the responsibility of external
tools, not the Axiom core itself.

> GUI and Axiom core also fall in here.  Here's an interesting one - if
> we need to run the Axiom core without a multi-threaded lisp, how do we
> stop a job that is running too long?  Killing it is a bit drastic,
> since that also loses us any other computations done before, but what
> alternatives are there?
For starters we could just use a multi-threaded Lisp. If that fails we
might be able to use Unix signals (or an equivalent mechanism) and
several processes. In the beginning we might have to live with an
Axiom that doesn't behave very well.

> 4.  Global document structure - in some ways, a Mathematical GUI must
> also be a document processor.  Mathematica certainly is.  How do we
> handle that issue?  What typesetting engines are available, and which
> are suited for interactive work? 
Depends on the GUI. Not everyone wants to write articles using his
CAS. Some people just want to calculate a few integrals every now and
then. Those GUIs that want to do document processing will figure out a
way to do it. That problem isn't really specific to Axiom.

>> 2) We modify the Axiom core to allow easy development of GUIs. People
>>    start building them, first simple, then more involved ones. We
>>    pick the 'best'.
>> 
>>    What if two years later a different GUI is much better? Do we
>>    change the canonical GUI? For how long does it have to be the
>>    better one?
>
> That's why I prefer we have our own, that takes good ideas wherever
> they are found and incorporates them.
And is always last on new developments, and looks like a random
collection of CAS GUI features.

>> Since a single GUI might support several system at once (see Bill's
>> work), why not turn the whole thing upside-down? People download
>> bundles consisting of a single GUI and several cores (Axiom, GAP,
>> whatever).
>
> Because those systems, fundamentally, are not designed to work
> together.  I admire the SAGE effort and I think it will be very useful,
> but GAP (for example) doesn't share Axiom's type system and so there is
> an impediance mismatch between the two systems.  What assumptions is
> GAP making that Axiom doesn't know about when it solves a problem, and
> are those assumptions ones that are compatible with the ones we would
> make?  Does a function name or even a property name mean the same thing
> between the two systems?  If we evolve towards proving algorithms, how
> do we prove an algorithm used in GAP without doing enough work to go
> ahead and implement it in Axiom anyway?  
Just because you use two CASs from the same GUI doesn't imply that
they'll have to work together. In my Emacs I use Common Lisp and
Haskell, which don't understand each other either. On the other hand
this whole point isn't that important, so let's ignore it for now.

>> PS: I don't mean to say that there shouldn't be a nice, downloadable
>> package on Axiom's website featuring a specific GUI. What I'm after
>> is independence. Axiom's main branch should contain no GUI-related
>> code other than the implementation of the Axiom<->GUI protocol.
>  
> Well, maybe.  But I think there should be an axiom-gui tree as well
> that has the "official" Axiom GUI, which the Axiom project keeps in
> sync with any changes to the Axiom core.  And when we build the
That would mean that not all GUIs are created equal. There will always
be tricks the official GUI can do, that other GUIs aren't capable
of. If the Axiom core has a new feature that requires it to break
compatibility with older GUI versions, will the release of that feature
have to wait for the official GUI to catch up? Even if alternative
GUIs already support it?

> complete "system" we should build axiom-gui as well.  We already build
> the Hyperdoc program, after all, and that is part of the default
> system.  I'd rather have axiom-gui as a directory in the toplevel axiom
> branch, and have a ./configure --without-gui option if one doesn't want
> it.  When I type .configure  make  make install and then run "axiom" I
> would kind of expect the GUI to be the default.
In my view the GUI should take care of presenting the documentation as
well. No separate HyperDoc program. Of course, nothing stops you from
building a terminal-like UI and supply a separate HyperDoc with that.


I have the impression that there are quite a few things that we just
won't agree on. Since my arguments are often based on speculation I'm
not really willing to push them much harder. Maybe we could instead
try to find a common ground. How about the following:

1) In the Axiom core we create one or more additional Lisp packages
   (in the DEFPACKAGE sense) that provide an API for all the services
   that a GUI needs/wants/whatever.

   The most important feature would probably be to get the output from
   textual chatter to something with more structure.

2) We add a *small* and *simple* piece of code that exports that API
   over a socket interface. We also add a commandline option to enable
   this feature/configure the port/etc.


Kai