Re: [Axiom-developer] Terms of Surrender (was: BAD tim)

[C Y]

--- William Sit <address@hidden> wrote:

> C Y wrote:
> > I'm just saying that in an open source project discussion without
> > code ultimately goes nowhere.  I don't think that's a danger here,
> > but it has been known to effectively kill projects in the past.
> 
> Is that (projects getting killed) necessarily bad?

Well, I guess I was sort of viewing it as a waste.  I suppose other
views are possible.

> > Spad does of course depend on the underlying modules, but shouldn't
> > it (in theory) not need to care how they are implemented?  Sort of
> > the same way ANSI lisp code should run in any ANSI lisp 
> > implementation, without worrying about how the enviroment 
> > underneath it is coded up?
> 
> True, but we are talking about maintaining the system, not just the
> algebra code. There are bound to be modifications, if only because 
> versions of Lisp has changed.

True enough, but those will hopefully be minor.  (A lot of fixes to
Maxima have been this sort of thing - tracking different versions of
Lisps - so I admit it happens.)  I think it depends in part on how much
non-standardized (e.g. non ANSI) functionality we need or want to use.

> Even my limited experience tells me that codes will break if allowed
> to stay stagnant.

Also true, unfortunately.

> > If I'm not mistaken, the approach Tim has taken so far with vol5 is
> > resulting in documentation that applies equally well to Lisp and
> > Boot code - at least, the level of documentation he has started 
> > writing.  If it helps, perhaps the current state of included auto-
> > generated lisp code could represent proof that the current 
> > documentation is in fact applicable to both Boot and Lisp code 
> > (where the documentation covers such things instead of SPAD code) 
> > since they are demonstrably identical at this stage.  If you parse
> > out the lisp includes and build the book again, viola - documented
> > boot code.
> 
> Glad to know that.

I should admit that's based on a casual inspection of vol5 - I haven't
yet read through it in detail or actually tried generating a Boot only
file.  But the structure of printing both Boot and Lisp code together
suggests it would be possible to omit the autogenerated lisp and still
have a viable document.

> Tim has done that type of analysis on Axiom more than anyone else.
> But what I am looking for is even coarser: just the major components
> and how Lisp helps.

Ah, got it.

> > My original vision was that each package would have one of these
> > types of graphs as it's second page (sort of an "inside the cover"
> > addition if it were a book) that would allow a new programmer to 
> > immediately get a feel for the workflow of this particular part of
> > the system, and what parts it relates to.  Maybe this could apply 
> > to pamphlets.  Also it might allow programmers unfamiliar with how 
> > the system works to quickly zero in on which functions were 
> > possibly relevant to a particular bug.
> > For real fun perhaps these diagrams could be autogenerated by the
> > SPAD/Aldor parser as part of the compile :-).  Of course, higher
> > level ones might have to be done by hand, depending on how smart
> > the output routines were...
> 
> That would be useful for Tim's Crystal vision.

Tim, could a compiler output diagram information files or is that not
really viable?

Cheers,
CY



        
                
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com