--- Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> Oh yes. If you google for "GCC" and "compile-time performance", you
> should have longish threads. I know of at least one coorporate who
> takes that issue very seriously (long before it became an issue for
> the whole community) and was willing to pay contractors to improve
> the compile-time performance.
OK, that's good to bear in mind.
> | Would increased power for chunk syntax be (in your opinion)
> | sufficient justification for a slower build? To me the question
> | is not an obvious one, and I was hoping some more people would
> | weigh in on this point.
>
> Indeed, it is not obvious. Last time we talked about it, the
> increase was oder of magnitude. Do you have new data?
You mean my original code vs. the finite state machine? The original
code was almost certainly neither fast or flexible, so it's out. Of
more interest is Steve's new work. I don't know how it does on speed
trials. Steve, have you had a chance to run any benchmarks?
> Do you have a summary of what is gained, what is lost?
> I've heard people upset because their development environements are
> broken.
That's only a consequence of changing from <<>>= to \begin{chunk}... I
don't have any particular opinion about that personally, but I am
beginning to share Steve's concern that we shouldn't be trying to
replace the weave step. We can still weave \begin{chunk}... just as
well as <<>>= - it's all just strings, in the end - but if we aren't
getting rid of weave I prefer the <<>>= syntax - less typing ;-). It
also has the benefit of Emacs modes which are already working.
Of more concern is the rather interesting possibility of chunks that
are intended to appear in neither a woven document (in the current
sense) or a tangled document. The possibility of such environments, or
other (more elaborate) behavior would make LaTeX processing
increasingly complex and in some cases would necessitate a weave step
anyway (short of implementing some things in TeX that it wasn't really
designed for, as far as I can tell...) The deeper concern is that
making an assumption of no weaving step constrains what can be done
with chunks, and I am thinking there is some merit to that concern.
So here are the pros and cons as I currently know them, without doing a
detailed study and benchmarking of Steve's new code:
Finite State solution:
+ Very fast
- Inherently complex
- Not flexible in what chunk syntax it allows
+ Can be extended to support <<chunkname>>[option1,option2]=
Other solutions:
+ Simpler to code and understand
- Probably slower
+ Flexible with respect to syntax
+ Can be extended to support arbitrary chunk structures.
Whether syntax flexibility is a plus or a minus depends on your
priorities - personally I favor enforcing one (fairly strict) structure
with the options extension, rather than allowing a new chunk start to
also serve as a chunk terminator and other noweb abilities. It makes
processing easier for the finite state machine, but I would prefer that
anyway - for me, a uniform, easy to parse chunk style is also easier to
read.
>
> | > (2) we should not gratuitously break development environments.
> |
> | You mean things like Emacs modes?
>
> Yes -- I think that is part of people's concern...
Unless I'm missing something, the use of \begin{chunk}{ instead of <<
and other such substitutions is the only hangup for that type of issue.
Hopefully, judicious string substitution in the .el files defining
the modes would be all that is needed. However, losing the weave step
as a basic assumption, as outlined by Steve, have potential long term
implications.
(I would be curious how AucTeX handles the verbatim environment -
presumably its handling of that would relate to its formatting of chunk
environments of this type. mmm-mode I'm less sure about, presumably it
would simply need to know about the new strings...)
> | Exactly - I want to get to the part where we ARE dealing with
> | abstract theorems, and in the computer too ;-). Until we get this
> | set up properly, we can't.
>
> My point is that the fundamental technology that drives the computers
> is moving fast, and you're aiming at a moving target. That is unlike
> the fundmental technology behind abstract algebra.
A Lisp environment isn't a moving target, most of the time - at least
the ANSI Lisp specification hasn't moved in many years. That's the
whole point of high level languages and specifications in the first
place - to abstract the logic above the computer technology of the day
and make something well defined to target.
There are of course situations where you can't do that (GCC being an
obvious example, and the Lisp itself being another) but I don't think
this part of Axiom should need to be sensitive to the platform it is
running on - any ANSI Lisp environment should be sufficient. There is
functionality we will need for other things that is NOT covered by the
spec (sockets, graphics) but I don't think the weave and tangle steps
need it. (Other functionality will of course, but that comes later.)
My take on this is to create tools now that cover all the needs we can
forsee, and are easily extended if we meet needs that we can't see. My
hope is that <<chunkname>>[options]= would be general enough to cover
what is needed. If I am alone in my preference for strict syntax, that
is probably not true and a finite state machine trying to be that
flexible may prove too convoluted to be maintainable or extendable.
There is of course nothing that says we can't have two implementations
of this functionality - one simple and flexible and one tuned and
complex. Chapters one and two in volume 4 ;-). Indeed, a good
explanation of a simpler tool might actually be useful background for
the state machine solution. Maybe Axiom's tangle/weave system could
even respect the whole "safety" system for lisp compiling and use the
slower solution when the safey settings are more conservative.
Cheers,
CY
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news,
photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
