[Axiom-developer] steps towards better TeXmacs interface

[Andrey G. Grozin]

Hello *,

If some program (e.g., TeXmacs) wants to communicate with axiom (via 
pipes), it must know in a reliable way, where axiom prompts begin and end, 
when axiom waits for input, where parts of axiom output written in LaTeX 
begin and end, which parts of output are error messages, information about 
the type of the expression just calculated, etc. In order to do so 
reliably, axiom has to insert some (parametrized) markers at some key 
positions of its output. Approach based on partial parsing of the plain 
text output is (1) unreliable (as a user, I can print any string, and 
confuse the interface); (2) ugly (axiom already knows where are its 
prompts, but this information is not obvious in its plain-text output; why 
should the interface guess, if axiom can tell it for sure?). The current 
interface (written by me long ago) uses this last approach.

Another free computer algebra system, maxima, has incorporated inserting 
of parametrized markers in the key positions of its output some time ago. 
Now it is easy to interface it to almost any external program: one just 
assigns appropriate values to the marker strings, and then maxima speaks 
the protocol required by this external program. Maxima developers called 
this "the transition from the stone age to the bronze age" (the idea is 
that using corba or some such thing would be the enlightment era).

Axiom is still in the stone age in this respect (a more structured and 
predictable input-output). I am now trying to move it to the bronze age. 
The first (and rather obvious) place is interp/i-util.boot.pamphlet
I renamed the procedure MKPROMPT to MKPROMPT0, and inserted

$InterfaceStrings : Record(PromptPrefix:String,PromptSuffix:String) := 
['"[",'"]"]

MKPROMPT() ==
  
STRCONC($InterfaceStrings.PromptPrefix,MKPROMPT0(),$InterfaceStrings.PromptSuffix)

This works, and my prompts are now in brackets (of course, this is just a 
test). The next step is to find all the other prompt-like things in axiom 
(i.e., output strings immediately preceeding user input). One of them is 
the exit confirmation, for example; I'm sure there are many others. Each 
prompt-like string should now be preceeded by 
$InterfaceStrings.PromptPrefix and followed by 
$InterfaceStrings.PromptSuffix . And this is only the first step, there 
will be, e.g., $InterfaceStrings.LatexPrefix and 
$InterfaceStrings.LatexSuffix and some other markers.

So, I have a few questions to the gurus:

1. What is the correct file to put the definition and initialisation of 
$InterfaceStrings ?

2. Is there some way in which this initialisation could be made dependent 
on external conditions? For example, can I pass a command-line argument to 
AXIOMsys, and check it in boot code? Or check an environment variable in 
the boot code?
At the moment, I know only one way to pass some information to axiom: 
.axiom.input. But it would not be a good idea for TeXmacs, for example, to 
overwrite the user's .axiom.input (if the user has one).

Making text exchanges between axiom and an external program to follow some 
structured, predictable protocol (without playing guessing games) is the 
first and the most important goal. But there are further necessary steps. 
The current TeX generation (algebra/tex.spad.pamphlet) was written 15 
years ago. Naturally, it does not produce modern standard LaTeX. I've made 
a number of changes in tex.spad.pamphlet, to produce more 
standards-complying LaTeX code instead of some historic relicts ( \over , 
\sub , \root ... \of ... , etc.). But this is not exactly what's needed. 
TeXmacs has some strange requirements of its own (e.g., using \* for 
multiplication). Therefore, I want to leave the old TeX generation alone, 
and to introduce the new kind of output: texmacs. So that it will be 
possible to say
)set output texmacs on
OK, I can easily duplicate tex.spad.pamphlet (should this be a new file, 
texmacs.spad.pamphlet, or I just double the contents of tex.spad.pamphlet 
?) I'll rename the domain TexFormat to TexmacsFormat, and make the 
improvements I want. But what to do next? My (very incomplete...) 
understanding is that I should insert the necessary pieces into 
setvars.boot.pamphlet and setvart.boot.pamphlet (based on the TeX pieces, 
with renamings and some small changes). But setvars.boot.pamphlet says 
that if I change the boot code (and I'm going to do this), I have to 
translate it to lisp and insert it into the same file. How do I do this, 
exactly?

The new domain TexmacsFormat is the natural place to put the line-breaking 
functionality. Some ideas can be taken from the C code which does such 
line-breaking, and which is available. Of course, it is much more natural 
to do this in the spad domain, where all the information about the 
expression structure is available. Also, this C code generates LaTeX which 
gives a reasonably-looking output, but is mathematically meaningless (it 
uses \array's all over the place for things which are not arrays). This 
leads to the fact that, if this C code is used, it is absolutely 
impossible (and never will be possible) to copy a (part of) output by the 
mouse and insert in into an input field (because it is not possible to 
reconstruct the mathematical meaning of an expression from this obfuscated 
LaTeX). And this goal is highly desirable. Therefore, the aim of 
TexmacsForm will be to generate a meaningful LaTeX, with line breaking, 
which can be used as a source of drag-and-drop in TeXmacs.

There is another possibility, which requires some thought. What if we send 
expression tree from axiom to TeXmacs as an S-expression, instead of 
serializing it via LaTeX? TeXmacs understands not only latex: fields, but 
also scheme: fields. Generating scheme syntax from an axiom expression may 
well be easier than generating LaTeX. Line breaking can be done on the 
TeXmacs side, where the necessary information is available (it is in 
principle impossible to tell, what is the width of a sub-expression after 
typesetting, without actually typesetting it). But this is, probably, a 
more long-term project. For now, I'd better keep as much as possible from 
the current interface, but make it more robust and less ugly.

What do you think?

Andrey