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 _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer