[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] steps towards better TeXmacs interface
Andrey G. Grozin
[Axiom-developer] steps towards better TeXmacs interface
Fri, 26 Aug 2005 23:32:44 +0700 (NOVST)
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) :=
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
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,
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?