[Axiom-developer] Hyperdoc

[daly]

Martin,

Sorry for the delay in your question about working together on 
the hyperdoc issue. I've been giving it some thought. I have a
long term view of the "porting problem" which might be different
from your (or anyone else's) view so this is purely my opinion.
I'd welcome feedback on it.

For me the current hyperdoc is "so last year". The issue is not that it
uses old-looking technology. Hyperdoc shows a lot of the features
found in current browsers and was way ahead of its time.  However, I
want to do things now that are "way ahead of their time" so that 30
years from now the complaint will be that the world has finally caught
up.

There is the fundamental design issue, which I've been calling the
"Crystal" problem. It involves a multi-faceted view of a single
unified core problem. Lets ignore the deeper issues of the embedded
semantic network, the "intentional stance tracking", etc and just
focus on the low-level technology issues.

I've been doing isolated "experiments" to try to test these tools
to see what they can now do and find things they still need to do
(e.g. the lisp replacement for javascript does not yet do <canvas>).
The experiments are simply learning exercises to try to find the
limits of what the current tools do. But there are some low-level
goals that lie behind these exercises:

END-TO-END-LISP

I see the lisp as the base of axiom all the way to the base of the
web browser. End-to-end lisp is important because it gives me a lot
of power with very little work. I can dynamically create executable
expressions that can be evaluated in the browser and/or in the axiom
image. 

With tools like Hunchentoot I can map URLs directly into lisp function
calls. This means that I can dynamically create pages and hyperlinks
and have them execute function calls. Thus URLs can be created to
directly execute algebra, to dynamically create hyperdoc pages, etc.
<http://weitz.de/hunchentoot>

With Kamen Lisp (which replaces javascript in the browser) I can 
dynamically upload/download lisp functions. I can remotely manipulate
the document structure. I can communicate between multiple tabs so
that one tab can have the "worksheet" and another can have an axiom
workspace where I try axiom expressions. I can have multiple browser
windows communicating with each other so that I can manipulate a
graphics object in one window (e.g. rotate, scale, subset, etc) and
have the corresponding expression show up in another window. 
<http://www.cs.stevens.edu/~dlong/software/kamen/index.php>

With Apache I can configure it to talk to lisp and axiom directly
<http://www.accela.net/~dankna/guide.html>
Thus I can have apache manage the connections. If Axiom is
configured to sit directly behind apache I have the option of
having each browser tab be a separate axiom session, or the tab
could have its own workspace (axiom supports multiple workspaces)
or I have have them all share a session. Indeed I could have
a tab open to an axiom running on a different server entirely.

BROWSER DOES GRAPHICS

A near term goal is to lift the graphics out of the C code and
into lisp. Once this is done the graphics can be dynamically
manipulated by lisp and lisp can be dynamically manipulated by
the graphics. Thus the algebra code can interact directly with
the image allowing things like continous rotation (lisp drives
the graphics) or have data from the graph be transmitted back
to the algebra (e.g. picking the endpoints of the domain of
a function, deciding control points of inflection, interactive
root finding, etc).

This opens the way for doing things like solid modeling where
I can use Axiom to compute the stresses and strains in the
model where it takes input from forces applied by the user.

I can manipulate strings of primitive objects (folding, twisting,
attaching) to shape objects which know how to self-assemble since
I can keep the operations in a data structure parallel to the
graphics. Replaying the data structure on a primitive string
re-folds the object.

The tools to do this are the <canvas> tag and Kamen lisp on the
front end and a lisp-based graphics/algebra connection on the
back end. 

I also see a tighter connection between the graphics and the
axiom data structures. So if I create a complex graph object
(such as the dependency graph of the algebra) I can see the
graph object drawn directly from the algebra. If I implement
a "cost" primitive it would be possible to compute the cost of
a computation and show the computational costs of an algorithm
on the graph. Geometric objects (sheaves, splines, manifolds)
can be visualized an manipulated "visually" while the computation
occurs in parallel symbolically.


BROWSER DOES HYPERDOC

Hyperdoc also needs to be lifted into lisp and made a more integral
part of the system. Hyperdoc needs to know how to handle pamphlet
files directly, that is, how to construct html from the pamphlet
and pamphlets from input from the browser. This would allow the 
documentation to live in the pamphlet files. It would also allow
dynamic documentation (e.g. new algebra domains recently compiled)
to be shown. Since lisp has access to all of the algebra there is
a wide range of searching capabilities that could be implemented
(e.g. show all domains such that domain D has property P.

The internal language of the documentation for Axiom is latex. The
back end needs to know how to convert this to html (e.g. by using
tex2html or some tool like it) and from html to latex. Further we
need to think about things like MathML (I've done no experiments
with this yet).

BROWSER DOES FORMATTED I/O

For the browser front-end to be useful in the long term we need to
be able to manipulate the equations using tools like cut and paste.
It should be possible to select a subset of an equation, clip it,
or paste over it, and then see the computation repeated with the
change. History needs to be easily manipulated. Web pages with
results (e.g. as a notebook) need to be able to be exported as 
pamphlet files. The user should be able to use the browser as a
complete front end, doing input, output, and interaction (e.g. such
as graphics rotations which are sent back). It should be possible
to visit other sites, clip an equation, and have it entered into
the system.

BROWSER DOES DRAG-AND-DROP

It is important that we be able to take a pamphlet file, drag it
onto the browser, and have it added to the system. This facility
is fundamental to the idea that literate papers at a conference,
or from a web publication, can be immediately added. The user 
should be able to do things like change the equations in the paper
and see tables derived from the equation updated in real time.
Bibliographic links should be fetchable in an ASDF or YUM-like
form so that literate papers can reference other literate papers.

Pamphlet integration is vital to the long term front end.

FACETS

Once we enter into the idea of the crystal we introduce the idea of a
facet, which is a view into a piece of information about a unified
problem. The facets are all connected, giving multiple views of the
same problem while tracking the user's intentional stance. Facets
are found by rotating the crystal.

There's more but it takes us off into areas that only I care about
(as if we're not there already) such as a semantic network problem
representation and the interaction with the facets.

I'm basically tracking toward the crystal idea and focused on the
long term design. Thus I'm not spending a whole lot of time thinking
about porting issues. I don't see porting issues as being fundamental
in the long term view. I don't think the current design is sufficient
to carry us much further into the future. Indeed it is hardly sufficient
to carry us between platforms. I think it needs to be created anew.

t