Newsgroups: comp.object,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!yale!zip.eecs.umich.edu!newsxfer.itd.umich.edu!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!lyra.csx.cam.ac.uk!warwick!uknet!festival!edcogsci!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Subject: Re: Why Commit to Eiffel?
Message-ID: <Cw4q13.25I@cogsci.ed.ac.uk>
Sender: usenet@cogsci.ed.ac.uk (C News Software)
Nntp-Posting-Host: bute.aiai.ed.ac.uk
Organization: AIAI, University of Edinburgh, Scotland
References: <DOUG.94Sep6154321@monet.ads.com> <Cw30D5.63q@cogsci.ed.ac.uk> <DOUG.94Sep13175937@monet.ads.com>
Date: Wed, 14 Sep 1994 17:03:03 GMT
Lines: 141
Xref: glinda.oz.cs.cmu.edu comp.object:20437 comp.lang.lisp:14670

In article <DOUG.94Sep13175937@monet.ads.com> doug@monet.ads.com (Doug Morgan) writes:
>In article <Cw30D5.63q@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
>|In article <DOUG.94Sep6154321@monet.ads.com> doug@monet.ads.com (Doug Morgan) writes:
>|
>|>I like Lisp, but this list seems to be make light of real problems
>|>with the Common Lisp standard (e.g., "Know thy compiler" can easily
>|>become an unproductive full-time job.)  Here is a sampling of details
>|>(possibly a few years out of date):
>|
>|Most of them I agree with, but ...
>|
>|9. No free down-to-the-hardware full-up compilers.
>|
>|CMU CL?
>
>I'm still confused about how I ever wrote this.  Also, GCL and
>ECoLisp, perhaps.

KCL and hence presumably GCL compile via C.  I wasn't sure that
counted, since it prevents optimizations not expressible in C
(ok, may be some in-line assembler, but that's not what KCL
does at least).

>|>15. No static name overloading.  Wart-filled name selections and
>|>    argument conventions haphazardly developed through 40 years of
>|>    growth and merge.
>|
>|That's not really so.  Common Lisp was a tremendous cleanup
>|compared to a number of earlier Lisps.  I'm not sure what you
>|have in mind by "argument conventions".
>
>I was thinking about things like:
>
>(aref        thing index)
>(get         thing index)
>(gethash     index thing)
>(nth         index thing)
>(assoc       index thing)
>(elt         thing index)
>(getf        thing index)
>(find        index thing)
>(member      index thing)
>(nthcdr      index thing)
>(rassoc      index thing)
>(slot-value  thing index)
>(intern      index thing)
>(find-symbol index thing)
>
>14 names with no pattern to show they all do some kind of lookup.  5
>have the "mapping" as the first argument, 9 as the second.  Maybe
>having the unrelated names can be justified, but I doubt that the
>various argument orders can.

Those are good examples.  But note that asymmetries and the like
are possible (indeed common) in a single Lisp.  It isn't necessary
to have years of buildup.  Consider e.g. PLUS and TIMES vs QUOTIENT 
and DIFFERENCE in early Lisps.  Also, your examples mostly fall 
into two groups which we might call: indexing (aref, elt, slot-value)
and lookup (gethash, assoc, find, member, intern, find-symbol),
where lookup is more like searching.  Oddities are then nth, nthcdr,
get, and getf.  (I've written assoc for assoc and rassoc and may have
missed some here or there.)

This i far from perfect, but it makes sense for array indexes
and the like to be last.  But then, member, find, and some others
seem reasonably natural the other way around.  Natural languages
are often full of such stuff, so it's presumably not too hard
for people to deal with.

I think it's pretty easy for languages and libraries of procedures
to turn out this way w/o any help from "backwards compatibility"
unless a deliberate and determined effort is made to stop it.
That's the main reason Scheme is more regular (following Yale's T).

>|They used to be able to.  There were reasons for changing the spec.
>|I don't think it's fair to call this a defect w/o taking those reasons
>|into account.
>
>I do assume there were good reasons.  I just don't like the results.

I've sometimes been annoyed by it as well, and by some other
X3J13 decisions.  In this case, deftype is often useful.

>|>19. CLOS has no provisions for optimizing methods for special cases
>|>    like
>|>        O single argument dispatch
>|>        O classes with no further (or with restricted) sub classes
>|>        O I know the class is *exactly* such-and-such right here.
>|>    (Calling upon meta-object protocol doesn't really count.)
>|
>|Implementations can do much of this themsleves.  A number of them
>|optimize single-arg dispatch, for instance.
>
>For multiargument generic functions that just happen to only
>specialize on one argument?  If so, that's pretty good.  I would have
>thought that this optimization (and the other ones) would be too
>expensive without some mechanism for the user to "tell" CLOS about
>expected usage.

Humm.  I suppose I should try to check exactly what various
implementations do (if the implementors will say), but it's
pretty to see some possibilities once you start to think about it.

For instance, what usually happens when a generic function is
called is that it (a) computes an "effective" method for the
argument classes in question (combining befores, afters, etc)
and (b) caches it for quick lookup the next time.  The cache
can be a decision tree (or think of a finite state machine)
with one step/link for each arg.  So if only the first arg
is ever specialized, the cache would go directly to a method
rather than to another branching node.  It's also possible
to notice that all methods are like that (spec only on 1st arg)
and replace the generic's lookup code with code that's more 
specialized, if that would help.

In addition it's possible to optimize cases such as: only one method
exists (check the class and go) and all methods are slot accessors
(do the access rather than call a method that does it).

These techniques rely on adjusting things at run time.  Such
optimizations might be cleared if a new method is defined for
a gf (or if a class is redefined) and then built up again when
the gf is next called.  (More sophisticated versions are possible.)
So it may be that the first call to a gf, or the first call for
a given combination of arg classes, is slow.  For most applications,
that's ok.

>|>23. Maybe Dick Gabriel had a good point in saying that Lisp is "the
>|>    right thing" but that the "worse-is-better" C++ approach is
>|>    destined to win.  Of course, Lucid lost on both big-time,
>|
>|They did?  That's not what I've heard.  (But I could easily be
>|wrong.)
>
>Somehow my jab at the worse-is-better idea missed the mark here.  I
>hope the idea is completely wrong and Lisp does wonderfully.

I meant that I'd heard they were done in by the C++ side.
I was the "both" I was questioning, rather than anything else.

-- jeff
