--- William Sit <[EMAIL PROTECTED]> 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
_______________________________________________
Axiom-developer mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/axiom-developer
