[Axiom-developer] Axiom and common lisp tools

[daly]

Martin,

> Did you care to look at SandboxHyperDocReplacement? Your mail makes me a
> little angry, I must confess.

I'm sorry that you have an emotional reaction to my exploration of the
space of possible solutions. I didn't set out to anger you.

Your code is not the first attempt at making web pages from Axiom
and it certainly won't be the last. You wrote some lisp and spad
and then suggested that SOMEONE should write it up as a pamphlet.

The only available someone is you. Ideas come up all the time but
in order to make them live you have to champion them by writing them
up (ala Cliff's cl-web), implement them, test them, sell them to others,
integrate them, and push them out as a useable patch to Axiom. Kai
worked on a solution during one summer. Unfortunately I was switching
jobs that summer so I couldn't participate and no-one else carried
it to fruition.

We've have various "handwaving" attempts at this in the past and 
will have more in the future until one of us or someone new does the
required work to make their idea the standard because they implemented
it, etc. Then we will all have something that we can all complain about. 

I've been looking at this issue since Bill Page joined this effort
years ago. He insisted that the only reasonable path for Hyperdoc
replacement was a web browser. It took him a while to convince me.
Now I'm convinced. I have a simple version running locally but its
not ready to be introduced to the world.



But my view of a "solution" involves more issues than your code
addresses. A good solution to the browser front end should eventually
remove all of the cross-platform issues we have and make the user
interface more useful. So I see a lot of constraints on the browser
issue that are not addressed by the current proposed solutions such
as yours. 

We need to think about the 30 year horizon. The solution needs vision.
It needs to go well beyond what exists today.

Given a browser front end:

  how do we communicate without hanging axiom?

  how do we communicate without running many axioms?
  how do we handle multiple sessions?
    (axiom can handle multiple workspaces)

    (are axiom pages related to tabs? is each tab a workspace?)

    (can tabs communicate? can tabs work in parallel?)

    (can multiple browsers connect to the same session? 
     this would allow two people to communicate results, 
     which might be interesting in a classroom setting)

  how do we handle requests for dynamic content?
    (axiom knows the libraries but the documentation connection
     is weak. someone recently suggested output of the function
     comments should be added to the )d op ... command)

    (axiom uses pamphlets. there needs to be an architecture for
     displaying links to and for displaying the contents of pamphlets)

    (axiom documentation needs structure that gets generated dynamically.
     how is this going to be done?)

    (axiom needs the ability to show examples of each domain. 
     these examples should be able to be changed, similar to the way
     hyperdoc does now with the "DO IT" button)

    (axiom needs a fast, structured search that includes concepts as
     well as text strings so we can find ideas as well as known functions.
     this requires some idea like enhancing the pamphlets with \concept
     tags and constructing index pages during build)

  how do we handle graphics?
    (axiom pre-generates some graphic content in hyperdoc so it can be
     shown inline in static pages. these inline images contain enough
     information to launch the graphics as a live image)
   
    (axiom generates live images on request and these live images can
     be manipulated with a control panel. HTML has a <canvas> tag that
     allows dynamic drawing on the screen. the graphics piece can write
     into a <canvas> area)

    (axiom can handle the graphics as "expressions" if the interface
     is done right. the easiest case would be to allow a user to
     click a bounding box and then redraw the graphics with the new
     bounds. this is different from the current purely-graphical
     manipulations we do)

    (once axiom can draw into a <canvas> tag we could begin to develop
     other kinds of graphics such as graphing the algebra hierarchy or
     the spad data structures or piecharts, etc)

  how do we handle output?
    (axiom generates latex now. 
     should it generate html? 
     should the translation occur inside the interface?
     do we make output as images or as live text?)

    (if the toolchain is common lisp we could dynamically construct
     s-expressions that could be evaluated anywhere along the chain
     (in spad, in the interpreter, in the web interface, in the browser)
     this would allow us to construct domain calls in the browser,
     evaluate them in axiom, and send them back to the front end)

  how do we handle input?
    (is input still 1D or do we consider 2D?
     how would we linearize 2D input?
     how do we handle piles with variable-sized fonts?
     can the user select subexpressions?
     can the user click on the type output and see something interesting?)

    (this is the web so it should be possible to visit other pages and
     communicate equations back to axiom. how can this work?)

  how can we handle drag-and-drop?
    (axiom pamphlets are the basis of an ongoing discussion for a
     live journal. we'd like to be able to just drag-and-drop new
     pamphlets onto axiom and have it "just work". how does this
     work? how does it interact with the build?)

  how do we minimize the tool requirements?
     (axiom should "just work". we don't want to get into the business
      of requiring java, perl, javascript, XML, flash, mysql, and the
      half-a-hundred other extensions)

     (axiom uses common lisp (as an assembly language :-) ). it appears
      that this toolchain i proposed is all-lisp, all-the-time) 

  how do we integrate this into axiom?
    (axiom does most of its graphics work at the spad level. can we
     figure out how to make the input/compute/output occur and be
     controlled by spad domains?)

    (can the axiom interpreter be raised to the spad level so it
     can by controlled by a spad domain?)

  how do we integrate this into the build?
    (your web page shows spad-level code which would make for a very
     interesting way to "raise the level" of handling the interaction)

    (the one web page shows ASDF code that would fit easily into the
     ANSI build sequence)


To do this "right" is a much harder problem than it seems.

I'm interested in the toolchain I posted because it gives us an
end-to-end common lisp solution. Thus we can dynamically construct
content at either the browser end or the axiom end. It eliminates
javascript/html/php/etc. and makes it possible to push functionality
to the best possible place in the pipe at runtime. We could push
expressions that contain particular domains in either direction.

And the hack on the web page I pointed to shows a way to make URL
page names turn into common lisp function calls. That means that
some of the pages can be completely dynamic.

     




> By the way, if you start replacing LaTeX by something else, you are going to
> loose me.

Me? Replace latex? Surely you jest. Or misread. I'm the guy pushing latex
all the time, everywhere. Latex, common lisp, and spad make up my list of
tools. All else is overhead.

Latex is the only documentation standard I feel we should pursue.
I'm hoping to find someone who has built a browser that speaks latex
rather than html. 

I'm the guy trying to rewrite the pamphlets to eliminate noweb and
just make everything into latex.

I can't imagine why you think i might start replacing latex.

Tim