[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] latex and noweb
From: |
daly |
Subject: |
[Axiom-developer] latex and noweb |
Date: |
Fri, 4 May 2007 09:47:55 -0500 |
Cliff, Ralf,
I'd suggest we think about pamphlets as a domain and think about what
operations make sense in the domain.
I'd suggest we move up a level in the design. We need a couple tools
with crisp definitions. This would allow us to decompose and recompose
a pamphlet file. Then we can use these functions to define lisp, spad,
or aldor code that plays with pamphlet files in the same way.
Then we could write "algorithms" to do the various processing. For
instance, Ralf could write a code-decoration algorithm that
post-processes the nodes that represent code and adds font, color. In
general, every user could have their own use for pamphlets.
We could run who-calls on the lisp code and add that information as a
special section.
We could write an index node that gets added to the document with
information we preprocess. Thus we could cross-reference with links.
We could decorate code nodes with "next code block" hyperlinks.
Thus you could walk the nodes in "code" order.
We could hyperlink bibliographic entries to other pamphlets or
to outside sources.
We could use these functions interactively either behind the
scenes in a web-serving axiom or directly in user )help requests
Pamphlets() ==
parse(pamphlet) -> graph
take a pamphlet structure and generate a graph of that structure.
the graph would allow us to identify parts of the pamphlet as nodes.
each node would contain the text and some start/end/type information.
for example, the preamble, the body, the postamble.
within these other nodes could be recognized as needed and made
reachable. this is similar to the document format idea in javascript.
nodetype(pamphlet, point, list recognizer) -> nodetype
each node would have a predicate that recognizes the node type
the nodetype function applies each recognizer and returns the
type of the next block. the nodetype contains position and
extent information.
nodetypes might be both straight latex and axiom nodes, e.g.
\body node
\preamble node
\tableofcontents node
\section node
\usepackage node
\bibliography node
\chunk node
\spadcommand node
etc
recognize?(typename, pamphlet, point) -> boolean
we could have recognizers for the whole document, a \usepackage line,
the \printindex line, the \section line, the \begin{chunk} line, etc.
hash(pamphlet) -> hashtable
take a pamphlet structure and develop a hash table of all of the
code segments. this already exists in gclweb.lisp
tangle(hashtable, chunkname) -> code
take a hash of the chunks and a primary name and return the
tangled code
decorate(hashtable, chunkname) -> decoratedcode
take a chunkname and return the code in latex form with \hyper
\index, \font, and other decorations in latex form
addnode(graph, node) -> graph
take a graph at any node and rewrite the graph at that node.
deletenode(graph, node) -> graph
take a graph at any node and rewrite the graph at that node.
replacenode(graph, node, node) -> graph
take a graph at any node and rewrite the graph at that node.
createnode() -> node
make a new, blank node
eval(commandnode) -> latex-result
run a command in a \spadcommand and return the latex result
eval(graphicscmd) -> ps-result
run a graphics command and return the \includegraphics and ps
regress(command,result) -> boolean
run a command and compare it against the result
Tim