RE: [Axiom-developer] axiom common lisp

[Bill Page]

On November 17, 2005 5:12 PM Tim Daly wrote:

> 
> what are the semantics of these operations?
> 
> evalandfileactq
> rdefiostream
> rplq
> *lam
> mdef
> comp370
> remove-fluids
> dcqexp
> 
> unless you happen to have the documentation for vmlisp handy
> it's unlikely you'll be able to decide or even guess. future
> generations won't even have vmlisp available. i spoke to Fred
> Blair (the vmlisp author) and he doesn't even have a copy of
> the sources.

That is irrelevant. We have up to date definitions of the exact
semantics of all of these in Axiom right now. For example, I go
to

http://wiki.axiom-developer.org/axiom--test--1/src/interp

I enter 'evalandfileactq' in the search box and hit Enter. I see
where it is used and that it is defined in 'vmlisp.lisp' I click
on

http://wiki.axiom-developer.org/axiom--test--1/src/interp/VmlispLisp

and choose 'pdf'. In about 15 seconds I know that

(defmacro evalandfileactq (name &optional (form name))
'(eval-when (eval load) ,form))

If someone had bothered to write one or two sentences in English
about the usage, I might be happier, but as long as I know that it
works in GCL and how to read lisp, then this is enough to define
the semantics isn't it? I don't care that much about the history.

> 
> rdefiostream creates filenames which follow VM/CMS conventions
> 8char.8char.1char (filename, filetype, filemode (disk name))
> do we want to carry this convention into the future?
> 

It's not hard to find the defun for redefiostream in nlib.lisp.
Of course without some documentation it is a little hard to
decode the logic of this 30 line function but as far as I can
tell it no longer imposes the 8 character name limit.


> the other operations are equally obscure. there are more where
> they came from. their semantics pervade the sources and unless
> you understand their semantics you'll never guess why filenames
> have such weird restrictions.

Looking at some of the others it seems to me that the only
reason these seem obscure is because of lack of documentation.

> 
> so i can document and educate the users on the weird file i/o
> semantic differences or simply write it out of the code and
> adopt proper ansi common lisp conventions.
>

I would definitely opt for the first option first. We can adopt
proper ansi common lisp conventions later.
 
> only my questionable expertise in vmlisp allows me to maintain
> this code. i want it to go away so others can maintain/modify
> and expand it.
> 

Really, Tim I don't think it is as hard as you make it out to
be. The main thing that seems to be preventing other people
from helping to maintain, modify and expand it is their lack
of time and interest. I really doubt that your rewriting all
of this according to modern conventions will make much
difference to the availability of people willing to work on
the internals of Axiom.

Regards,
Bill Page.