[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: Bill Page
Subject: RE: [Axiom-developer] Terms of Surrender (was: BAD tim)
Date: Sun, 6 Nov 2005 12:59:50 -0500


On November 6, 2005 1:16 PM you wrote:
> in open source "advocacy is volunteering"
> are you volunteering to write the "boot" compiler docs
> and maintain it? can you set it up as a separate language
> so we don't need to bootstrap it? you could write bookvol10
> (boot language).

I agree that "advocacy is volunteering" so yes volunteering
to document boot is the least I can do, having spent so much
bandwidth and sweat trying to defend it. :)

> to do that you'll have to figure out what parts of axiom
> are only there to support boot and you'll have to recode
> the portions of the boot compiler that is written in lisp.

I know it wont be easy. I wasn't thinking in terms of recoding
anything from lisp to boot or vice versa - just providing a
sound documentation of the design and use of boot as it stands
> will you redo the boot language to support ansi destructuring
> setq? structures? mcclim? clos? macros? defvars?

I don't see why this should be necessary. Boot already supports
destructuring setq.

> the bottom line is that without these facilities axiom won't
> be able to use the latest lisp developments. we will have
> essentially forked the lisp used by axiom. this is something
> i do not want to do.

I agree. I think that some ansi constructs can be introduced
without any changes to boot - simply using the escape to lisp
where necessary as explained by Jergen.

> we are already off the leading edge of ansi.

I am not sure what you mean by that.

> yet developing those new boot facilities takes me off into
> designing extensions and enhancements to a language i don't
> like. and it's a big project. Jenks and Burge spent a lot of
> time on it. why the feature-debating alone could take years!

I also do not want that.

> if we're going to enhance a language i'd much rather the time
> and energy went into debating new ideas for the spad language.

I agree completely.

> since this is open source development you're welcome to
> document, support, and enhance boot. for my part, i see no
> good reason for it to live so i'm certainly not going to
> spend my time on this.

No problem. I understand your view, even though I don't agree.
I just didn't like the feeling of my going in this direction
while you seem to be going in exactly the opposite. That is
the reason I am looking for a compromise.

> i'm advocating literate programming and have likely committed
> the rest of my axiom working life to proving (or disproving)
> the concept.

Three cheers! On this we are in complete agreement. I agree
100% with the emphasis on literate programming - so much so
that I have a hard time understanding why you feel that it
might be necessary to prove it.

> t
> (btw, axiom lisp has a destructuring setq (which i ported
> from maclisp). we just don't use it. see doDSETQ and *DCQ*
> in vmlisp.lisp. the boot compiler SHOULD use it but does not)

Thanks, that is interesting. I will look into this a little
more. Do you know if Spad makes any use of these macros?

Bill Page.

reply via email to

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