[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Terms of Surrender (was: BAD tim)
From: |
C Y |
Subject: |
Re: [Axiom-developer] Terms of Surrender (was: BAD tim) |
Date: |
Tue, 8 Nov 2005 06:05:40 -0800 (PST) |
--- 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
- Re: [Axiom-developer] security and trust in Axiom (was: Bootstrapping), (continued)
- Re: [Axiom-developer] letting my mud settle, Mike Dewar, 2005/11/09
- RE: [Axiom-developer] letting my mud settle, Bill Page, 2005/11/09
- Re: [Axiom-developer] letting my mud settle, root, 2005/11/09
- RE: [Axiom-developer] letting my mud settle, Bill Page, 2005/11/09
- Re: [Axiom-developer] letting my mud settle, Mike Dewar, 2005/11/09
- Re: [Axiom-developer] Terms of Surrender (was: BAD tim), William Sit, 2005/11/08
- Re: [Axiom-developer] Terms of Surrender (was: BAD tim),
C Y <=
- Re: [Axiom-developer] Terms of Surrender (was: BAD tim), William Sit, 2005/11/07
- RE: [Axiom-developer] Terms of Surrender (was: BAD tim), Bill Page, 2005/11/06
- Re: [Axiom-developer] Terms of Surrender (was: BAD tim), William Sit, 2005/11/07
- Re: [Axiom-developer] Terms of Surrender (was: BAD tim), Martin Rubey, 2005/11/07
- Re: [Axiom-developer] Terms of Surrender (was: BAD tim), William Sit, 2005/11/07