RE: [Axiom-developer] A Canonical Axiom GUI

[Bill Page]

C Y <address@hidden> writes:
> ... 
>>>> 1.  I think a default GUI for Axiom would be a Very Good Thing
>>
>>Kai Kaminski wrote:
>>> As I said, I'm not convinced.

I am convinced that trying to build a graphical user interface that
works only with Axiom would *not* be a good thing.

> >
> > No worries.  There is plenty of room here for differing 
> > opinions :-).
>
On September 8, 2006 9:56 AM Kai Kaminski wrote:
> Don't kid yourself. There's barely enough room for mine. ;-)
>

I do appreciate the sentiment in Kai's remark, which he indicates
we should take as humour. But I am worried that some people who are
potential contributors to this discussion might well perceive it
as fact. If so, I think that is very unfortunate. Axiom is a very
small project in terms of the number of active and vocal developers
so it is easy to give the wrong impression. My opinions about Axiom
development differ from other people on this list on a number of
points and I don't feel shy about saying so. Is that setting an
example or reinforcing the feeling that there is no more room for
other opinions? :(

Perhaps we need to do more to make sure that people feel like there
is room here for differing opinions and that we would really like to
hear them.

>>>> 2.  The project is not yet at 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.

Yes!

>>> 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.

While I would welcome anyone interesting in working on Axiom at the
level of the Lisp code, I seriously doubt whether compatibility of
Axiom with other open source Lisp libraries would make Axiom more
"friendly" to such developers. Or did you have some specific
libraries in mind that would have immediate application and mass
appeal?

>>
>> Right.  What I meant 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...

Thanks Kai :-). Yes, I am glad that only one Axiom developer seems
to be actively wasting his time on the idea of eliminating higher
level languages from Axiom... ;)

About ANSI lisp and licensing Aldor as open source, I agree that
indeed these are pressing problems - even "mission critical"
problems! If we don't solve these soon, I have little hope for the
immediate future of Axiom let alone the next 30 years.

> 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?

It should not and it isn't.

> 
>>>> 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.

Having already implemented several user interfaces for Axiom, e.g.
TeXmacs, MathAction, AxiomUI and (soon) Sage, we do know very well the
kind of information and communications protocols that would make these
systems easier to program and more robust.

> ... 
>>
>> 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). 
> ...

I am afraid that I have to agree with Kai. We should not be tempted
to try to use Axiom as a fulcrum on which to lever renewed interest
in Lisp. To do so would almost certainly crush Axiom. In contrast to
the situation when most of Axiom was designed and implemented, there
are many other programming languages available today that are capable
of supporting Axiom and this is especially true when it comes to GUI
development.

>> 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.

On September 8, 2006 12:24 PM C Y wrote:
> 
> Eventually, yes I do.  Existing work should be used as a guide,
> but I think the eventual goal should be a plotting library so
> good/robust/capable that it makes no sense to use anything else.

No! This is open source and it's the 21st century. We should *never*
be thinking about re-writing other people's code. We need to be able
to collaborate with other projects and make direct use of other
people's work whenever we can. This is a philosophy that is deeply
embedded in the Sage project and I think it is largely responsible
for why it has become a major new computer algebra project is less
than two years - about the same amount of time we have been discussing
this GUI issue... The sooner we understand this philosophy the more
likely it is that we can save Axiom from the ghetto.
 
> ...
> Earlier C Y wrote:
>> 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.
>

The critical thing here is to design an asynchronous communications
protocol that allows the GUI process and the calculation engine to
work independently but in a co-operative manner.

I think we should pay close attention to the Twisted library currently
implemented in Python

http://twistedmatrix.com/trac

Twisted will very likely be used in the next version of Sage to improve
the Sage NoteBook GUI interface. It is especially suitable for use with
AJAX methods for web browser interface design.

If there is any similar kind of "event-driven networking framework"
that has already been implemented in multi-threaded lisp then that
might be of immediate interest. But even without such a library, as
Kai says it would possible to implement this as, say a Python process
running Twisted that communicates with the Axiom core is a more
primitive way.

> ... 
>>> 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).

Yes indeed. There has already been some interest expressed on the
part of the Sage Notebook developers to extend the Notebook interface
to work with Axiom. This is quite different than providing a direct
Sage interface to Axiom itself, for example the way Sage interfaces
with Maxima now.

>>
>> 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 impedance mismatch between the two systems.

This mismatch exists and is (largely) solved right now in Sage
between GAP, Singular and Maxima.

>> 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?

In principle this sounds like a really hard problem and it has even
given rise to a really big attempt at a general solution in the form
of OpenMath, but Sage ignores almost all of this and is a successful
demonstration that in practice this is not such a big problem. Sage
provides it's own dynamic strongly-typed object-oriented language
(actually just Python!) that serves as an interlingua between otherwise
quite different systems. It is interesting to note that this is the
same method that Martin Rubey used in Axiom to encapsulate Polymake.

> 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?

??? GAP already provides some tools for proving algorithms written
in GAP. Obviously the thing to do is to make use of these tools
where they exist.

> 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.
> ...

I disagree that it is not important. To me, helping to provide a high
quality Axiom interface for Sage should be one of our highest priority
tasks at this time. The sooner we do this, the less we risk being
further marginalized by the success of this new open source project.
And because in contrast to those systems which already have an interface
with Sage, Axiom was built with an object-oriented philosophy very
similar to (in fact I would say, much more advanced than) Sage, I think
Axiom has a lot to offer the Sage project.

> 
> 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.
>

Yes!
 
> 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.
> 

Yes, yes!

> > Kai Kaminski writes:
> >
> > | 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.
> >
> Gabriel Dos Reis writes:
> > I agree with that.  If you can sell it to the powers, I would be
> > happy to lend a helping hand.
>
> On September 8, 2006 7:14 AM Kai Kaminski wrote:
> Thanks. Maybe we can just agree that having an API/protocol to the
> Axiom core is useful anyway and then implement that. That way we
> avoid the discussion about whether we need a canonical GUI or not. The
> existence of a well-designed API seems to be a good idea anyway.
> 
> I'll try to put up a wiki page for collecting design proposals, use
> cases, etc. Furthermore I'll try to document those parts of Axiom that
> are directly related to this effort (plotting code, database access,
> documentation access, access to the interpreter/compiler etc).
> 

Kai, it you need any help or further incentive to start such a wiki
page please let me know. :)

On September 8, 2006 10:26 AM Martin Rubey wrote:
> ... 
> For display only I think there are three possibilities:
> 
> * use OutputForm directly
> * use TEX
> * create a domain like TEX that takes something in OutputFrom 
>   and converts it to whatever you want
> 
> For input and reusing output you should probably extend INFORM.
> If the type of a result of a computation doesn't have INFORM, you
> should complain to the author of the domain, or realize that it
> would be very very hard to come up with an INFORM.
> 

I think Martin's point is very important: that input and output
in Axiom are "designed in" to Axiom domains at a very fundamental
level. Therefore it is probably not practical nor desirable to try
to achieve a situation where the "Axiom main branch contain no
GUI-related code other than the implementation of the Axiom<->GUI
protocol".

But if by GUI-related you mean hyperdoc and Axiom graphics as opposed
to AXIOMsys itself, then I agree that these should not be considered
part of the core. Only AXIOMsys needs to be instrumented for an
external API.

As a bare minimum we need the kind of interface designed by James
Amundson for Maxima and used by A. G. Grozin in the TeXmacs interface
for Maxima. See http://wiki.axiom-developer.org/SandBoxMaxima
But I think that for Axiom we can do even better than that and
accommodate many other kinds of information such as Axiom types,
graphics data, and Axiom database (daase) queries.

Regards,
Bill Page.