axiom-developer
[Top][All Lists]
Advanced

[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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]