Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!ut-sally!utah-cs!shebs
From: shebs@utah-cs.UUCP (Stanley Shebs)
Newsgroups: net.lang.lisp
Subject: Re: Against the Tide of Common LISP
Message-ID: <3838@utah-cs.UUCP>
Date: Sun, 29-Jun-86 18:51:00 EDT
Article-I.D.: utah-cs.3838
Posted: Sun Jun 29 18:51:00 1986
Date-Received: Mon, 30-Jun-86 06:00:49 EDT
References: <830@bu-cs.UUCP>
Reply-To: shebs@utah-cs.UUCP (Stanley Shebs)
Organization: University of Utah CS Dept
Lines: 53

In article <830@bu-cs.UUCP> bzs@bu-cs.UUCP (Barry Shein) writes:

>Try writing a (savework) function in CL which saves off everything
>you typed in (functions, variables etc) in a re-readable form, it
>can be done I suppose, but just try a general attack (don't forget
>packages...)

I'm not 100% clear on why DRIBBLE is not the right thing, but I don't
think that Franz or PSL have any magical features that make it more
possible to write such a function...

>Where is the user environment anyhow? It's not there, every vendor
>gets to make it up and in so doing will add a zillion (+-3) functions.
>Will *this* be part of CL? No. Will programs 'accidently' use these
>vendor supplied functions to make things useable? Yes.
>Will your code run on other CLs? No.

There is some debate about that very point, and the consensus seems
to be that the LISP package should be pure and not contain anything
not already defined in the standard.  So if programmers stick to using
the lisp package they'll be OK for porting.  Alas, some implementations
still export all kinds of crud out of the LISP package.

Consider the alternative, which would be to have a language standard
that did not allow any extensions.  Imagine the howls of outrage from
Symbolics when the user environment is required to be a read-eval-print
loop.  Imagine the howls of outrage from Unix people if the standard
is changed to require at least 4 extra bits on each character, and
keyboard shift keys to go with them.  Imagine howls of outrage from
everybody if the implementation had to be designed such that it was
impossible to redefine builtin functions (improves portability, right?).

>Other than lexical scoping and macros (which I hate except in very
>few situations) hopefully this can all be fixed by a CL/2 which
>actually addresses the issues of -using- the language. Right now
>it's obviously a set of lowest-common-denominators among a few vendors,
>designed by a committee obviously and skirting almost all the interesting
>issues.

Well, they strayed into attempts to define fancy character sets and
file system interfaces, and the results are pretty disastrous.  Some
things are better left unspecified by a standard...

If you have a proposal for what the user environment should look like,
by all means let's hear it!  Remember that you have to accommodate fancy
interfaces on Lisp machines and dumb terminals on IBMs and everything
else in between.

>This could be the beginning of a long dark ages for LISP.

Hmmm, I thought it was the *end* of the Dark Ages! :-)

>	-Barry Shein, Boston University