[Top][All Lists]

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

[Axiom-developer] Re: gclweb.lisp

From: C Y
Subject: [Axiom-developer] Re: gclweb.lisp
Date: Wed, 2 May 2007 19:49:17 -0700 (PDT)

--- address@hidden wrote:

> Ralf,
> gclweb is only intended as an interim hack until we move to ANSI,
> at which point I expect that the CWK algorithms will be used.

Hmm.  Tim, looking at the TeX output from the noweb command it's a tad
more involved than I originally expected.  It should be possible to
handle it, but in order to cover the general cases needed it will
probably require some deeper digging into the why of various commands
to check for corner case behavior specs.  I have a couple quick
orientation questions if you happen to know the answers:

1.  The generated names such as NWcl*P-cop9-1 clearly are not assigned
at random, but are based on the chunk name combined with some other
strings.  Is this merely for readability when assigning unique labels
or does the structure of that name/label have a functional significance
to the style file?

2.  The list of chunks at the end of the file appears to be sorted in
alphabetical order by the first non-numeric character in the chunk name
- is that sort order necessary?

The function of things like nwbegincode, nwendcode, nwbegindocs and
nwenddocs is readily apparent, and for whatever reason each chunk and
documentation region is assigned a number, bumped each time a new
region is defined (all chunks have odd numbers, all doc regions even
ones). The ones I'm not quite following yet are nwdocspar,
nwixlogsorted, nwixd, are nwixu.

One design question I'll ask now, because it will impact how work goes
forward - should the initial scan of the buffer do all the work needed
and place it in the structure, or should the extra steps only be taken
if a separate scan function is called?  I would not expect a drastic
increase in scan time but most likely there would be some, if for no
other reason than the extra assignment work to be done.  Do we want to
have a "pure" tangle that does only what is needed for the machine
code, or should we have one scan function that records all info needed?

> We should, however, debate the question of what FUNCTION we want
> out of the pamphlets, as opposed to style and form. Do we want
> hyperlinking,


> biblographic references,

My vote is a very definite yes, obviously.  Better to have the key
information in the pamphlet as opposed to buried in an obscure research
paper someone would have to see $30 to see, and in that case we need to
cite sources.  Anyway, I would think references would be needed for
algorithms in any case?

> unit and regression testing,

I'm sort of torn here.  Certainly I think we need these tools and full
documentation of the tests (why they've been selected, references,
etc), but I'm not sure how they relate to pamphlets.  I take it you are
thinking of a specific chunk structure for unit tests?  Hmm.

> URL parsing, 

Doesn't the hyperref latex package already handle URLs?  What
functionality did you have in mind?

> )compile compatibility,

I certainly think this would be desirable.

> hyperdoc/html processing, drag-and-drop processing, user examples,

Not sure what you mean by html processing - output of latex to html
files?  Reading html formatted commands/files?  HTML output from LaTeX
is a non-trivial problem and most solutions are imperfect.  Not sure
about other issues yet.

> Since you've been pioneering the implementation of these ideas
> using ALLPROSE perhaps you can put together an initial proposal
> which we could maintain as "the pamphlet proposal". An initial
> version would be an outline of the ALLPROSE current function.

Agreed - such a document would be very useful.

> Style and form questions are much harder to debate because we
> have so many options. I feel we have to distinguish these from
> their intended function so we don't get hung up in the details.

Yes.  Style ultimately should be configurable anyway - the thing to
check there is that LaTeX packages used are compatible with each other.


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

reply via email to

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