🚀 go-pugleaf

In article <830@bu-cs.UUCP> bzs@bu-cs.UUCP writes:
>
>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.

Do you mean that this is a special property of CL? Foo! I've used
the same version of MacLisp on different machines and the user environments
can be totally different, depending of which features the local hackers
have included. Also there are different librarys which are supposed to exist,
programs just load them. This is a problem you never get around in any
interpreted, dynamic langauage.
Common Lisp is fairly well defined in environmental matters, especially, 
the I/O functions can not be better defined unless you make sertain 
assumptions about hardware and terminal capabilities.
Besides, will a Franzlisp program run in Interlisp? No. Will a Maclisp
program run in Franz'? Probably not. Will a CL program run in (another)
CL? Yes, if you don't use implementation dependent features not included in
the standard. It's up to you. (If you really *want* to loose so...)

>This could be the beginning of a long dark ages for LISP. Franz and
>Interlisp were/are far superior even if the compiler has to figure a
>few things out (what a waste of a human I suppose.) Others probably
>were/are also.

I think that, what You (and Jeffrey Jacobs) really mean is that CL does 
not look and behave like you are used to and therefore must be bad.
("I've hacked Lisp for ten years and know what a REAL Lisp looks like,
 so don't you come here with that new stuff!")
If people had thought that way the last twenty years we would still use
LISP 1.5 (the oldest version I've seen).


					PEM
-- 
Per-Erik Martin,  Computing Science Dep., Uppsala University, Sweden
UUCP: martin@kuling.UUCP  (...!{seismo,mcvax}!enea!kuling!martin)

It seems incredible to me that anyone would prefer Franz Lisp over
Common Lisp.  I recently had to convert a natural language front-end
written in Franz on a vax to Common Lisp on a Symbolics.  It was a
nightmare I hope I never have to go through again.  Functions
continuously mentioned variables that were defined in other files
(the program was spread out across 6 files).  There was no way to
know what was happening at any given time without extensive comments
(which were missing).  I never appreciated lexical scoping more than
I did then.  If Common Lisp is the dark ages compared to Franz Lisp,
then I plan on being very happy in my monastery surrounded by 
Symbolics and Explorers.

You cannot blame poor programming habits on the language; it's quite
feasible to write the same mess in Common LISP.

PLEASE NOTE: CL is NOT  lexically scoped; it allows BOTH dynamic and
lexical scoping, which makes the problem worse, not better.

It is possible to write bad programs in any language; it is possible to
write good programs in any language.

Jeffrey M. Jacobs, CONSART Systems Inc., Manhattan Beach, CA

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