Moon@STONY-BROOK.SCRC.SYMBOLICS.COM ("David A. Moon") (09/19/90)
Comments on some comments in Scheme digest v3n16:
UCI and 1.6 also had similar data types. What I meant to point out was
that the conceptual focus was on CONS cells and ATOMS as the *primary*
data types of interest. As opposed to modern Common LISPs, where the
term "atom" had disappeared,
Not so.
people are deathly afraid of using CONS cells,
Not in my experience.
and the focus
seems to be primarily on sequences, hash-tables, vectors, etc. (This
reached its peak in the SPICE litrature where users were warned to
'avoid the use of CONS whenever possible').
I think this is a bit of a misunderstanding. People were warned to
avoid consing new data objects of any type as much as possible, due to
the inefficient garbage collector used at that time in that implementation.
The problem with the function CONS they were being warned about was the
fact that it made a new object, not the specific type of object it made.
This comes from the colloquial use of the word "cons" to mean making any
kind of new object.
It's also true that with the advent of richer data structures,
programmers need to be advised to choose the appropriate data structure
for a task rather than always using linked lists for everything. I
certainly can't see the harm in that. Of course, a yet higher level
language than Lisp, which some of us might still yearn for, would
separate the issue of expressing the computation from the issue of
choosing the data representation, thus freeing the programmer from
thinking about all of these different data types all the time without
going back to nothing but linked lists.
True, but protecting the programmer from dumb mistakes is not something
for which LISP is famous.
I have to disagree with that. While it doesn't appear to have been
McCarthy's original goal, I think a case can be made that today
protecting the programmer from dumb mistakes is the key thing about
Lisp. If that isn't what rapid prototyping, good teaching language,
higher level programming, powerful application scripting language,
automatic storage management, and all that other noise is about, what
is?
>> Personally, I think the whole reason LISP machines were created
>> was so that people could run EMACS :-)
>I believe EMACS predated LISP machines by some margin
Hey, my point exactly. More (?) than one EMACS user on a PDP-10 brought
it to its knees, so the LISP machine had to be invented :-)
The truth is that Lisp machines predate Emacs by about two years, and
that the predecessors to Emacs in use at the time were not what brought
the pdp-10 to its knees. Not that it really matters.ericco@stew.ssl.berkeley.edu (Eric C. Olson) (09/20/90)
In article <19900919155917.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Moon@STONY-BROOK.SCRC.SYMBOLICS.COM ("David A. Moon") writes: >It's also true that with the advent of richer data structures, >programmers need to be advised to choose the appropriate data structure >for a task rather than always using linked lists for everything. I >certainly can't see the harm in that. I can. I think that using "appropriate" data structures makes code faster, but it also reduces that generality of the code. As someone once said, its better to have 90 programs that operate on one data structure than 90 programs that operate on 90 data structures. I think that using an array where a list will do is essentially hand compiling code. I'd rather have a compiler that would do this for me. I realize that what I'm suggesting is not feasible given the current state of the art compilers -- but it is what I want. Eric Eric ericco@ssl.berkeley.edu
lgm@cbnewsc.att.com (lawrence.g.mayka) (09/26/90)
In article <19900919155917.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM ("David A. Moon") writes: > certainly can't see the harm in that. Of course, a yet higher level > language than Lisp, which some of us might still yearn for, would > separate the issue of expressing the computation from the issue of > choosing the data representation, thus freeing the programmer from > thinking about all of these different data types all the time without > going back to nothing but linked lists. This is the prime motivation for object-oriented programming; and it requires not a new language, but rather: (1) Better optimization of Lisp's existing polymorphic operations (e.g., the sequence functions). (2) The progressive extension of CLOS' object-oriented programming capability to more and more of the preexisting Common Lisp functions and datatypes. That is, implementors should strive to progressively decrease the number of built-in classes (i.e., classes that cannot be inherited) and the number of non-generic functions (i.e., functions that cannot be specialized for a new class). Without sacrificing performance, of course! Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.