axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Re: Pamphlets and LaTex


From: C Y
Subject: Re: [Axiom-developer] Re: Pamphlets and LaTex
Date: Thu, 19 Jul 2007 05:20:20 -0700 (PDT)

--- Gabriel Dos Reis <address@hidden> wrote:

> C Y <address@hidden> writes:
> 
> | Gaby, you originally replied that you thought the speed was
> important:
> |
>
http://lists.nongnu.org/archive/html/axiom-developer/2007-02/msg00154.html
> | I would appreciate it if you could weigh in on this discussion,
> | when you get a chance. 
> 
> I have been trying desperately to stay quiet in this discussion. :-)

Auugh ;-).  Don't do that - I'm not the strongest advocate for speed
and speed was the reason for doing cl-web the way we did it.

> From my perspective, a replacement of noweb with a noticeable
> increase of build time is non tolerable.  I value developer time as
> much as  I value user time.  Longer build time means few build
cycles.
> 
> I'll seen the slippery slope in GCC come the point where even people
> who previously supported increase time will now ferociously fight any
> measurable increase, be it 0.5%.

I take it the concern is a lot of small slowdowns can mean a noticeably
large slowdown when added up?

> So my conclusion is:
> 
>   (1) ideally, we should not increase build time.  And if we must,
>       then there must be clearly identified benefits that we believe
>       are good for the long term.

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.

I think I can offer some flexibility with the inclusion of an options
box in the chunk syntax (no idea how noweb would react to that,
unfortunately...) that lets a developer designate a chunk as lisp,
SPAD, api, what have you.  Theoretically, a list of options with
information about the chunk would allow various functions to deal with
different types of chunks differently.  It would not allow an unlimited
range of syntax constructs, but I personally think a simple and
consistent style is its own reward.  A lot of the grief in web
development has come about because browsers attempted to work with
invalid syntax - it gave us joys like IE only websites.  I am very
dubious that additional syntax alternatives are worth the hassles they
can cause.

Although I personally prefer chunks that are visually well defined, as
I am thinking about it it may actually be possible (with some work) to
have a new chunk definition double as the end of the previous chunk -
do people actually want this?  It would also complicate any syntax
highlighting routines in an editor...  Is typing the extra @ really
that much of an inconvenience?
 
>   (2) we should not gratuitously break development environments.

You mean things like Emacs modes?

> | > So basically, if it is something you want to do, go for it :) If
> | > someone tells me they think some work of mine is flawed in some
> | > way that would not necessarily stop me from plugging away at it!
> | 
> | It's more a question of "what do I do to best forward the goal of
> | no one having to come back and do this again later?"  cl-web was
> | apparently a failure in that respect - my current goal is to
> | understand what needs to be done to ensure it doesn't happen again.
> 
> We are dealing with computers and software, not abstract theorems :-)

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.

I will attempt to go over Steve's code this weekend and see what he is
doing.

An appeal to any really skilled Lisp coders out there (oh Tim...) - can
you examine cl-web and give me some direction on how it might be
re-written to be more easily understood and maybe somewhat more
flexible without losing speed?  Does gclweb provide the same speed? 
Kai had some code that implemented a finite state machine generator,
perhaps I can revisit that and use it to make specifying the state
machine more easily understandable...

Perhaps it is not possible to both achieve the speed and keep the code
easily understandable/flexible, but I would like to arrive at a
solution in Lisp that everyone can support.

Cheers,
CY


       
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. 
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469




reply via email to

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