[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Literated VMLISP.LISP.PAMPHLET

From: Kai Kaminski
Subject: Re: [Axiom-developer] Literated VMLISP.LISP.PAMPHLET
Date: Tue, 26 Sep 2006 21:43:40 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (darwin)

Hi Tim,

I put your last two messages about the aliases in VMLISP.LISP
together, I hope you don't mind.

root <address@hidden> writes:

>> 1) Aliases in general aren't terribly useful.
> In general they are not. But if you want to provide porting
> functions that cover the semantics of two different functions
> it is useful in lisp to just store a pointer in the function
> cell of a symbol. It's a porting technique, not a useful
> idea in general.

> I should point out that you have to be VERY CAREFUL in axiom.
> Not all function names that are used show up in the source.
> This is NOT OBVIOUS. Axiom dynamically constructs some function
> names so you cannot just grep to decide if something is being
> used or not.
I thought so, which is one of the reasons I didn't actually remove
anything. If we remove a function that's actually used, we'll notice
pretty soon, though.

> Plus Axiom plays some optimization games. Functions are initially
> defined as 'autoload' which is just a trigger function. On first
> use the trigger function loads the actual code which replaces the
> function definition so it will have the correct definition on the
> second and subsequent uses. There are other automatic 'inline'
> operations that occur in order to speed up computation.
What is this optimizing for? Memory? Is it still necessary?

> At the present time the code rewrite is removing many of these
> functions completely. Bookvol5.pamphlet will not only be common 
> lisp but will be ANSi common lisp. The net effect is that files
> like vmlisp will go away.
That's what I was trying to help with. The whole thing grew out of the
recent GUI discussion. Since there is no broad consensus on the GUI
and several other questions, Cliff and I tried to find a minimal
common ground. We finally agreed that chunking up and documenting
Axiom's internals is a useful project, that anyone can participate


reply via email to

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