Newsgroups: comp.object,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!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: <Cw30D5.63q@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: <1994Sep6.000222.10384@rcmcon.com> <34i9hc$qfu@disuns2.epfl.ch> <DOUG.94Sep6154321@monet.ads.com>
Date: Tue, 13 Sep 1994 18:51:04 GMT
Lines: 68
Xref: glinda.oz.cs.cmu.edu comp.object:20395 comp.lang.lisp:14648

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?

>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".

>16. The spec allows dynamic-extent (stack processing) to be ignored by
>    the compiler.

So?  Virtually all language definitions allow inefficient,
even perverse, implementations.

>17. The spec allows declared types and optimizations to be ignored by
>    the compiler.  (Not even an implicit order of magnitude guarantee
>    on execution speed.)

But so do most specs.  Nothing says a C implementations can't
be just as inefficient, for instance.

>18. No standard way to find the declared type of a symbol.  (Also,
>    can't macro expand a declare, must expand an entire construct.)

Presumably you mean: a macro can't expand to a declare.

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.

>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.

>21. Last time I looked, CLIM had no provisions for full control of
>    color display lookup table hardware.  Hopefully, it has gotten
>    better.

CLIM isn't part of Common Lisp.

>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.)



