Xref: utzoo comp.lang.scheme:1740 comp.lang.lisp:3735
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!motcsd!mcdcup!mcdchg!att!cbnewsc!lgm
From: lgm@cbnewsc.att.com (lawrence.g.mayka)
Newsgroups: comp.lang.scheme,comp.lang.lisp
Subject: Re: Lisp history
Summary: Separation of algorithm from data representation
Message-ID: <1990Sep26.003657.20119@cbnewsc.att.com>
Date: 26 Sep 90 00:36:57 GMT
References: <19900919155917.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Followup-To: comp.lang.lisp
Organization: AT&T Bell Laboratories
Lines: 29

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.