Re: [Axiom-developer] Desired functionality from noweb

[C Y]

--- Ralf Hemmecke <address@hidden> wrote:

> >> -n      does not produce a latex wrapper (ALLPROSE provides a
> >> wrapper.)
> > 
> > OK.  That should be doable by locating the \begin{document} tag,
> > although we lose any special \usepackage commands if we do...
> 
> In ALLPROSE I follow the idea that there are projects. A project is 
> roughly something that you put together into a library. The project
> is  considered as a whole (although it might consist of several 
> files). A library should cover some area of mathematics. It is
> perhaps that what Tim had in mind when he wanted to put everything
> into just one pamphlet. 

I think we need to firm up what we want to do about such structuring as
a project before we commit to one particular style - this will have a
major impact on how people write documents for Axiom and as such is not
something to be decided lightly.

> I simply like the approach more if there are several files possible.
> Each project allows a .sty file where you can put any additional
> packages.

I'm trying to reconcile that idea with an "Axiom Journal" style of
writing where people may do shorter papers on a single topic.  Perhaps
if we pre-define projects for specific topics and have the style file
prepared for each topic, people could write for that "project" or
"topic".  In such a case MSC2000 might make a lot of sense as a
framework within which to define "projects".

> Sure, there might be problems with incompatible latex packages when
> one wants to produce a document that contains every such project. The

> combine latex package does not really do what you think. After
> reading the first document it redefines \usepackage to do nothing. So
> one cannot load packages later.

Perhaps the thing to do then is meet these issues as they arise.  If
we're going to break new ground in this respect we may have to upgrade
the tools on the LaTeX side as well.  If someone is writing for a
project and wants to use a particular package not already in the
project's style file we can resolve it on a case by case basis.

> I rather think that it still would be possible to produce crosslinks 
> over .dvi file boundaries. (Although I haven't yet produced any proof
> of concept.) That would be enough for me. If there is need to produce
> a 5000 pages book that should certainly be doable somehow, but I will
> not invest much time into that idea.

Fair enough.  I envisioned it more as volumes corresponding to toplevel
MSC categories - kind of the "Encyclopedia of Mechanized Mathematics"
or some such.

> > In the case of Lisp, I"m not quite sure how to do this in general. 
> > MOST of that information can probably be generated, but Lisp macros
> > would cause some difficulties in that department.
> 
> Also in Aldor it is not easy. If one wants to generate hyperlinks 
> without compiling the code, one has to follow some simple conventions
> so that a simple parser could find the relevant parts that should be
> turned into hyperlinks.

Ugh.  I wonder how much work it would be to get the SPAD compiler to
support what would be needed to properly support that automatically.
 
> But the "units" stuff would form a project in the above mentioned
> sense. So you are free to add any package you like.

That does make sense, but if we set up "projects" I would like to see
it done in such a way that naturally leads authors to finding the
"correct" project for a particular topic - otherwise, we may wind up
with several very similar "projects" that really should be part of the
same project but are still incompatible.  That's a fuzzy definition of
the problem, I'll have to think about how to state it better.

> > Out of curiosity Ralf, have you ever benchmarked ALLPROSE?  How
> > long would it take do you think to process something really large?
> 
> Why should I care? The only thing one has to translate is *one*
> project which should have reasonable size. If it works as I think,
> then there would be some kind of .aux files (of other project) with
> all the information in them to produce hyperlinks into earlier
> projects in the hierarchy. 

I am thinking about build times for Axiom.  Tim has stated that the
goal is to treat building documentation on an equal footing with
building machine binaries, so build time is impacted by documentation
decisions.  That's the whole reason Waldek proposed and implemented the
finite-state approach to tangle, and when I asked the list if it was
really necessary the consensus was yes.  

> If it takes one day to produce a 5000 pages book, why
> would that be a problem? How often do you think such a compilation is
> started?

Every time someone builds all of Axiom from source.  That happens
fairly frequently, and IMHO it should.

> You probably find ALLPROSE slow (I haven't really invested much time 
> optimizing it anyway), but for me functionality was/is more important
> than speed.

I haven't benchmarked it - I was just curious.  After spending all the
time generalizing and writing up the optimized tangle operation such
things come to mind ;-).

> I want to develop code+documentation and don't need to 
> produce a .dvi file every minute. Every 15 min should do. You know 
> yourself when you have modified big junks of text so that it would be
> wise to recompile. It is a bad idea to re-latex in the middle of
> writing since there are good chances that you get errors, because you
> have an unfinished environment.

Tim, that's a good question to direct your way - how often do you
re-latex your document?

> > I tend to think of it as one pamphlet = 1 "concept", and then
> > pamphlets would be bundled like conference proceedings to make
> > larger volumes.  It's the combining that makes it interesting.
> 
> But why do you think a "proceedings" form is the first thing we
> should think of.

Well, a journal then.  There has been serious talk of an Axiom Journal
and presumably the idea would be that such papers would end up as part
of the core system.  I don't know what the state of that idea is at the
moment (I expect it's on hold until Axiom is a reasonable platform for
such an effort) but I think in the long term it has merit.

> If everything is put into html form on a website what 
> disadvantage would that have?

Compared to LaTeX+pdf html is (at the moment) not as convenient for
mathematical output.  Since Axiom is intended to support advanced
mathematical research robust mathematical typesetting/output is a must.

> > In essence, links that move the reader through the document in the
> > order in which the machine would see the code?  That's not a bad
> > idea.  Hmm...
> 
> But that is only for chunks that have the same name. They are
> combined together in the order they apper in a .pamphlet. The rest
> appears as a hierarchy.

?  I'm a bit confused.  I thought chunk names had to be unique within a
pamphlet.

> I don't use language awareness in ALLPROSE. Aldor is not build-in
> into noweb anyway and I did not know how to write an appropriate
> noweb filter to add language support for Aldor, so my filters start
> before noweave sees the file. Anyway, if we start putting several
> different languages into one pamphlet, it will be difficult to guess
> the language if there is no explicit tag.

Agreed - I think it would be a bad idea to have more than one language
per pamphlet.  If we must do so an explicit tag for language is needed.

> I don't care much about LISP. I want to be language independent. And 
> perhaps add some features to support programming in Aldor. LISP is an

> assembly language for me.

Code highlighting and definition searching is inherently language
dependent.  The rest, I agree, has no need to be aware of any
particular language.

> Very important for me is that the pamphlet -> latex routine respects
> line numbers as noweave does. Every documentation chunk should be 
> wrapped by something like \begin{docchunk} ... \end{docchunk} and
> every code chunk by \begin{codechunk}{name} ... \end{codechunk} (or
> something similar.

Code chunks I've got wrapped in listing environments, but why do you
want the documentation chunks identified?  I always viewed pamphlet
files as a latex document with chunks embedded in it - what is the
advantage of chunking up the documentation as well?

Cheers,
CY


 
____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html