axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] RE: Leo, LP and Axiom


From: Bill Page
Subject: [Axiom-developer] RE: Leo, LP and Axiom
Date: Tue, 29 May 2007 19:47:29 -0400
User-agent: Webmail 4.0

Here is another installment of my continuing discussion with
the developers of Leo about the possible use of Leo in the
Axiom project. 

https://sourceforge.net/forum/message.php?msg_id=4335631

I would like to encourage you to also read the replies from
the Leo developers at the above link. 

--------

By: Bill Page (billpage) - 2007-05-29 19:42
In the wiki environment - which in some ways might not be
such a bad model for Leo - LaTeX encoding is often used
for "snippets" embedded in reST, MediaWiki, and even HTML. 
The "carrier language" takes care over the large-scale
formatting of the document or web page while LaTeX takes on
the role of a special sub-language for writing mathematical
formula and very rich sets of symbols. 

In Axiom another type of "snippet" contain computer algebra
input commands or even complete mathematical subroutines in
the Axiom programming language. 

The goal of "weave" is to produce a LaTeX script (or a script
in some other language, e.g. XSLT) that when later processed
by 'latex' (or other scriptable engine) will actually run
Axiom to compile these subroutines and execute the commands
producing additional output (often LaTeX-encoded) that is
merged with the LaTeX embedded snippets before finally being
rendered as a document (dvi, HTML, pdf, or whatever). 

Compare this to tangle whose specific purpose is to collect
source code and possibly commands into compilable units. 

Really these processes look nearly the same. They just operate
over differently rooted sub-trees of the Leo outline and
produce a different type of script on output while sharing
many cloned nodes. In both cases the "script package" may
consist of multiple files that are involved in producing a
final target product (or products) using standard system-
provided tools. 

So I am thinking that one should clearly distinguish between
the metadata, comments and notes that are part of the Leo
literate environment but not part of the final tangled
code (which will be run to produce a program), nor is it
part of the woven script that will be run to produce the
final documentation. These latter two are really just two
different kinds of "code" - one producing a program and
the other producing the documentation. 

Of course it is true that some of what starts out as metadata
comments might migrate to document or program content as
the  project matures. 

I think one thing that might be confusing Axiom developers
about Leo is that Leo really supports all three kinds of
content - metadata, documentation and code. But Axiom does
not have any means to systematically collect and manage the
metadata. The Axiom noweb files contain everthing (the possible
exception being comments contained in both the LaTeX and
program source code). 

The kind of model of have in mind for Leo is something like
you might see now in programs like PowerPoint, Microsoft WORD
and OpenOffice. The document consists of both the main content
which becomes part of the slides or paragraphs in the final
document *plus* other material such as collected comments,
change history, scope notes and briefing notes, statistics,
and other metadata that may or may not be printed along with
the product depending on ones final purpose. 

For literate programming I think there is a danger that not
everything that should be polished and presented will make
it into the final form. But from my point of view Leo has the
very great advantage of collecting and managing this working
information very early in the process. 

----

So having outlined all this, I would be very glad to hear  your
criticism and references to documentation about Leo that
might already address this points. 

Thanks for listening/reading to yet another overly long  post
on this subject. :-)

Regards,
Bill Page.




reply via email to

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