Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site yetti.UUCP
Path: utzoo!utcs!mnetor!yetti!mike
From: mike@yetti.UUCP (Mike Clarkson )
Newsgroups: net.lang.lisp
Subject: Vax/VMS Common Lisp : Version 1.1
Message-ID: <259@yetti.UUCP>
Date: Fri, 4-Oct-85 01:07:11 EDT
Article-I.D.: yetti.259
Posted: Fri Oct  4 01:07:11 1985
Date-Received: Fri, 4-Oct-85 08:41:16 EDT
Reply-To: mike@yetti.UUCP (Mike Clarkson )
Organization: York University Computer Science
Lines: 54
Keywords: VMS, Common Lisp
Summary: Never use Version 1.xx of anything.

[nibble, nibble.]

Digital has a Common Lisp implementation on Vax/VMS.  We have just
received it (the first site in Canada), and have yet to receive its
documentation so my exposure to it is rather cursory, but I thought
I might pass on some initial impressions.  It comes complete with an
EMACS style editor, and appears to be a complete implementation of
Common Lisp.

It's *BIG*.  The kernel is about 300 Vax pages (1 page = 512 bytes),
and then it boots the rest of it which is in a Lisp complied format.
The rest of it is > 6500 pages (>3 MEG!).  It requires 8600 pages (~4.5 MEG!) 
of virtual memory to run.  (In VMS this is the paging file quota.)

It's *SLOW*. We're running a Vax 8600 with 12 Meg memory, and under
normal load (50-60 users) it can take ~2 minutes just to load!  Garbage
collections on an 8600 at 3 a.m. with the system virtually user-free
can take 2-3 minutes.  (All timings very approximate.)

It's not bug free.  A number of simple things will make it turf its
cookies and die.  For example if you go into the editor and ask it
to add a line to one of the buffers using the GROW-WINDOW command,
all works well and the buffer is made one line larger.  However a
subsequent GROW-WINDOW command results in a fatal internal error in
the screen editor function GROW-WINDOW-HEIGHT routine as a result of
hitting a bad block address (SPR has been submitted).

This is version 1.1 so given that one should never use version 1.x of
anything I can't fault Dec (yet?).  However there's one thing I feel
is a major fault: unlike Franz Lisp which I am more familiar with,
this Common Lisp does not dynamically load, or "autoload" functions
that it doesn't have in it on an as-required basis.  This may be common to
Common Lisp, or maybe Dec didn't want source code lying around, but
the result is that it boots fully loaded, all dressed, and is slow
even if you don't need the whole works.  This strikes me as a poor idea.

In passing, I am very curious to know why Franz Lisp was not included in 
the set of languages that Common Lisp comprises, and what are the real 
philosophical differences that distinguish Common Lisp and Franz Lisp.  
Were there reasons why the people at Bezerkeley felt it would not be
advantageous to be a part of the Common Lisp "standard", or did they feel
that it would be better or simpler to add Common Lisp to Franz, rather
than changing Franz to conform to Common Lisp?  If anyone at Franz Inc.
has could shed any light on this question I would be very interested.
Either post replies, or mail to me and I'll summarise to the net.  I 
would also be interested in hearing about other people's experiences with 
Vax/VMS Common Lisp.


allegra \			Mike Clarkson,		     BITNET:
decvax   \			CRESS, York University,		FS300013@YUSOL
ihnp4	  > !utzoo!yetti!mike	4700 Keele Street,
linus	 /			North York, Ontario,	     AT&T^G:
watmath /			CANADA M3J 1P3.			(416) 667-3954