[Fwd: Re: [Axiom-developer] A Canonical Axiom GUI]

[Vanuxem Grégory]

Kai,


Thanks for your quick reply. I can not send a mail to you, gmx.de does
not accept mails from my ISP, so I send it here. In fact I wanted to
know why you think that  _Axiom is somewhat 'unfriendly' to program_,
but in general and not only about interfacing with textual chatters. I
misunderstood what you mean, sorry.

I agree with all you said in your mail about the mess of using the
AXIOMsys input/output in a UI. I think this is the method used by Sage
(with the pexpect python module), when the user works directly with GAP
or GP objects for example, and I have to say that I'm not a big fan of
this method. They will encounter the problems/annoyances you mentioned
when they will create the interface to Axiom.  A last thing, I think
that, yes, the creation of a well defined communication protocol, as you
argued in previous mails, is the way to begin/go. About communicating, I
have seen that some socket related routines have been added to Axiom but
it seems that they are not used. It's probably an anticipatory work of
Tim.

Again thanks,

Greg

P.S: I finally forwarded your mail to this list with some hesitations.

-------- Message transféré --------
De: Kai Kaminski <address@hidden>
À: Vanuxem Gregory <address@hidden>
Sujet: Re: [Axiom-developer] A Canonical Axiom GUI
Date: Thu, 14 Sep 2006 11:50:49 +0200

Vanuxem Gregory <address@hidden> writes:

>> -----Message d'origine-----
>> De : address@hidden
>> [mailto:address@hidden la
>> part de Kai Kaminski
>> Envoye : vendredi 8 septembre 2006 15:56
>> A : C Y
>> Cc : address@hidden
>> Objet : Re: [Axiom-developer] A Canonical Axiom GUI
>
> [...]
>
>> 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.
>
> Yes, please, when time permits.


Suppose you want to write a UI for Axiom (terminal app, Emacs mode,
GUI) that does more than just sending all user input to Axiom and
spitting out whatever Axiom prints. You encounter at least the
following problems/annoyances.

0) Right after startup Axiom displays a banner, which you have to
   ignore (in fact, you might even want to extract the version number,
   eg. for bug reports). Your UI starts AXIOMsys instead of axiom, so
   that error messages don't mess up the banner if X11 isn't running.

   Right after the banner there is either the prompt or random junk,
   depending on the content of ~/.axiom.input. What do you do with
   that junk?

1) How do you recognize the end of output?

   a) Wait until the next prompt/type signature/etc pops up.

      What if some user code prints something that resembles a
      prompt/type signature/etc? Also there are at least five
      different settings for the prompt. Other output options may or
      may not influence the display of the type signature.

   b) Wait until no more output comes.

      How do you know that nothing else will come down the pipe?


2) How do you extract meaningful data from the output?

   You'd probably be interested in things like

   - What is the IOindex of the last command? (The IOindex is the
     position in Axiom's history in that particular frame)

   - Did any errors occur? Which ones? Where?

   - Which type did the last result have?

   - What is the value of the last result?

   - What libraries were autoloaded because of the last command?

   - What other output did the last command produce?

   - What error/status messages did Axiom itself produce?

   There is no reliable way to do this, because whatever you think is
   a type signature, for example, could just be some output of the
   user that only looks like one.


3) How do you query Axiom for information?

   Suppose you want to get a list of the available domains. Sending
   ')wd' to Axiom does the trick. But again you have to parse some
   random, human-readable format that might not even contain all the
   information you're after.


4) How about integrating the HyperDoc and graphics subsystems in your
   GUI?

   First of all you'll have to open a number of AF_UNIX (why not
   AF_INET?)  sockets (good luck figuring out their names). Then you
   have to implement a number of binary protocols (yay!) that aren't
   documented anywhere.


5) How about Chinese?

   One would hope that eventually Axiom prints system messages in the
   language of its user. Now try to extract the information you need
   when all the messages are in Chinese.


There are ways around some of the problems described above. For
example, instead of sending user input directly to Axiom, you could
always send

  )lisp (foo ...)

where foo is a Lisp program that does what you want. Since you can
access everything from Lisp that would (probably) work. Needless to
say that it is messy, error-prone and relies on Axiom internals. Hence
you won't be able to change certain aspects of Axiom's implementation
without breaking foo, which breaks your UI.


The solution is quite simple. Instead of throwing textual chatter at
the UI, send structured data

(:result
  (:value some-structural-representation)
  (:type ("Fraction" "Integer"))
  (:presentation
    (:tex "\frac{5}{4}")
    (:ascii "5\\n-\\n4")
    (:mathml "???"))
  (:input-form "5/4")
  (:io-index 204)
  (:errors nil)
  (:warnings ((:low-memory "Running low on memory")))
  (:output nil)
  (:plot-data nil)

or, for the XML-inclined

<result>
  <value>5</value>
  ...
</result>

Axiom has all that information, emitting something like the above is
almost trivial. You now know when the output is complete (when a
well-formed answer has been received) and you can easily distinguish
all kinds of information.

Kai