Re: [Axiom-developer] ANSI Lisp?

[C Y]

--- root <address@hidden> wrote:

> yeah, it's coming eventually. i'm waiting for an ansi version of GCL
> which is "in process". 
> 
> it would be harder to port the whole build process to a "production
> version" that used another lisp than it would to do the ansi port.

Does this mean the build process is heavily dependant on GCL?  I
confess I haven't looked at it too closely, so I'm not sure what we're
using.  Lisp tradition would probably point to asdf as being a good,
standard, widely used way to organize the build of the lisp parts but I
don't know offhand how asdf and GCL get along.

I'd like to see Axiom at least on cmucl since that seems to currently
be the best platform for McCLIM, but I know that's not a compelling
reason by itself so I'll just wait for the ANSI shift and go from
there.  (While trying to figure out McCLIM in the meantime...)

> when i say "a few days" i really mean my normal, coffee-fueled,
> 24-hour hackathon kind of "few days". they are hard to find on a 
> part-time basis. when Axiom was a full-time job and IBM Research 
> would let me work at home i could burn a whole week and get great 
> things done. perhaps on my next vacation....

Darn it, I wish we could get some universities to sponsor a few folks
working on this thing.

> > A related topic: I recall you saying that you have once rewritten
> > all the  boot code in lisp? Does this code still exist?
> 
> nope. huge discussion. lots of religion. bad timing and all that
> rot...
> so i simply erased it. it's coming back again though. look at 
> src/interp/bookvol5.pamphlet in --patch-46

Would it be possible to put up a bookvol5.pdf somewhere?  My home
machine is off the net for a while and my Windows box at work doesn't 
have the necessary tools to handle pamphlet files.

> > Finally, I wonder whether you'd be able to fix the "bug" about
> > dependent types described in Issue #219...
> 
> i've decided that documenting the system is a higher priority than
> chasing bugs for me. 

Agreed!  Your knowledge of the system is not something we can easily
re-generate, which makes it uniquely valuable.  I think this is the
time for documentation, design polishing, and other things that are
long term rather than short term.  Reporting bugs is critical, because
it points out issues which need to be addressed as various parts of the
code are documented and made robust, but fixing them should (hopefully)
fall out of proper documentation and code review.  Design issues are
another matter of course, but Axiom seems to be designed well enough to
make it worth figuring out what the Right Way is ;-).

> if i chase bugs they die one at a time but there are hundreds of 
> them. if i cleanly, clearly document the system in a literate 
> fashion so others can read and understand it then other people
> can join in the bug fixing. of course, as i document the system i'm
> beginning to discover bugs and am fixing them as i go.

:-)  That's a good sign!

Cheers,
CY


                
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com