Re: [Axiom-developer] browser front end, statement of plans and progress

[Andrey G. Grozin]

On Fri, 26 Jan 2007, address@hidden wrote:
> I've been looking deeply into the problem of using a web browser
> as the front end for axiom. There are 3 components:
>
> 1) replace the graphics
> 2) replace hyperdoc
> 3) make an interactive front end
I still think that there is a better alternative than using a browser as a 
front-end - GNU TeXmacs. Browsers are big and inefficient (especially 
things like javascript); the quality of formulas is not really good. 
There are exactly 2 programs which cac display high-quality maths - TeX 
and TeXmacs, but TeX is non-interactive (attempts to run latex on each 
output line are terribly inefficient). TeXmacs can easily replace hyperdoc 
- it already has practically all the needed functionality, though sending 
commands to Axiom for execution will require some programming (not very 
much).

About graphics: the current graphics has a good feature that I can 
interact with a plot (to a limited extent) by mouse and menus, without 
re-running Axiom commands. I think this is very valuable, and should be 
much extended. Ideally, I should be able to rotate, zoom, change scale 
along each axis, change axis labelling, place light sources, chenge 
textures of surfaces, etc. etc., and produce a live plot of a ray-tracer 
quality. All of this is not possible in a browser. This requires opengl. 
So, moving to a browser interface seems to me a big step backwards.

> Architecturally the choice of making the graphics engine exist outside
> of the underlying lisp system has limitations. I would much rather see
> a closer integration between the computations and their display so that
> the display could be dynamic instead of static graphs. And it should be
> possible to create new domains that directly manipulate axiom data
> structures that can be drawn directly. A standalone C program is not
> a good choice for this.
Yes, a more close coupling between graphics and computations is very 
valuable. But why a browser? Its connection to Axiom computation engine is 
very week.

> Recently a new html tag <canvas> has been implemented. I've been playing
> with this tag and it appears to support all of the drawing primitives we
> need to do the 2D graphics. Axiom already does the 3D->2D work.
This is by far insufficient for highly interactive high-quality graphics.

> Another recent (well, recent to me) development has been the AJAX
> architecture. This allows a web page to dynamically and periodically
> communicate to a host without changing the page. This is how google
> does tricks like google earth.
Isn't it a way to spend a lot of resources (CPU, memory, bandwidth) for 
nothing?

> So combining these two technologies will allow us to run an axiom
> process that communicates with a local or remote browser and can
> dynamically draw shapes on the webpage.
Yes, if you are prepared to wait as long as for getting some responce from 
google earth (with network bandwidths outside USA, it is terrible).

> The low level task is to refactor the C code into display and
> data handling. The display primitives get pushed out to javascript.
> The data handling gets sucked into lisp. The C code disappears.
Javascript is 100 - 1000 times less efficient than C. Also, no opengl, no 
interactivity, etc.

> Consider problem 2, replace hyperdoc.
As I said, TeXmacs can do everything hyperdoc does. Now. A few lines of 
scheme code are needed to send commands back to Axiom.

> Hyperdoc used to have its own language for display but this is dead
> and gone. I've been recoding the hyperdoc pages into html so they
> use a standard format. This will allow anyone to code web pages without
> any training. It should also allow us to embed pamphlets as pdf in pages.
Pamphlets are LaTeX (or at least they should be, if your excellent idea of 
\begin{chunk} ... \end{chunk} will become reality). TeXmacs can display 
LaTeX (and hence pamphlets) directly, without pdf. It can also edit them 
in a wysiwyg fashiom, which you cannot do with pdf.

Also, re-coding hyperdoc pages to LaTeX should be easier than to html, and 
LaTeX is (from my point of view) a better language. It is already used in 
pamphlet files. Why introduce html for the help system? Why not to use 
LaTeX here too?

> Hyperdoc can display both static (easy) and dynamic (somewhat harder)
> graphics output so I'm stalled on the conversion while I work thru
> the graphics details.
TeXmacs can display static and dynamic graphics with equal ease, if it's 
.eps (or can be converted to .eps).

> Consider problem 3, make an interactive front end
>
> Given AJAX it should be possible to type into a web page, send the
> input to axiom, html (mathml?) the output, and display the result.
> This will take a bit of surgery on the axiom display internals and
> is queued behind the first two problems.
So much inefficient machinery for so simple task!

TeXmacs can send commands to Axiom right now. Currently, the communication 
in the opposite direction is done by Axiom generating LaTeX and TeXmacs 
displaying it. This should be changed. Serialization of formulas produced 
by Axiom via LaTeX, mathml or whatever is inefficient and loses important 
information. Parsing this text stream in a front-end is a senseless work, 
and should be eliminated. It is easy to output Axiom expressions as 
s-expressions, and to send them to TeXmacs, without losing any information 
about their internal structure and semantics. TeXmacs can understand and 
display formulas sent as s-expressions. Some small adjustments are needed, 
of course: TeXmacs expects s-expressions formed according to some (rather 
natural) rules. But it is, of course, *much* easier to write generation of 
such s-expressions than generation of LaTeX or mathml.

> The goal is to have a working browser-based front end to axiom
> that works on any platform or across the net by next year.
>
> By design all of the C code disappears and all work is done
> inside the lisp image. The actual functions will be implemented
> at the axiom/spad language level so that users can have complete
> control of I/O directly in spad.
>
> So the overall redesign calls for a lisp-only, browser fronted
> axiom which uses html (maybe mathml, undecided), javascript and
> a general browser (or any network program). All of the C code dies.
> All of the hyperdoc language/machinery dies. Sman dies. All axiom
> code is just a single lisp image.
Deth of C code, Lisp image only - this is good. But I am against browsers, 
mathml, javascript (which is as bad as C and *very* inefficient).

GNU TeXmacs is free and available on all platforms (recently, a Mac port 
with a native MacOS interface appeared, but I cannot comment on it because 
I don't have a Mac). It has an additional advantage: it is used as an 
interface to Axiom, maxima, yacas, Mathematica, Maple, REDUCE, MuPAD, 
Pari/GP, macaulay2, octave, scilab, matlab, R, ... (the list is too long 
to continue). A user can cut-and-paste between systems (for example, I can 
derive some large matrix in Axiom, and then to copy the Axiom output to 
Octave input for further efficient numerical diagonalization). Some 
improvements in TeXmacs will benefit many systems, not just Axiom. For 
example, I am sure that intelligent line-breaking for long output formulas 
should be written in scheme inside TeXmacs, then it will be used by Axiom, 
maxima, etc. etc.

To conclude: I think TeXmacs should become an official front-end for 
Axiom. If a browser front-end is an inevitable evil in our age, TeXmacs 
should become an official front-end number 2.

Best wishes and many thanks,
Andrey