Reasons for rejecting CLOS 
Author Message
 Reasons for rejecting CLOS


> I've been using OO languages for onwards of 15 years now (mainly C++ and
> Smalltalk, but also having some FLAVORS and CLOS experience).  There are a
> good many problems where sending a message to a single object does not make
> sense.

> Look at the double dispatch issue in arithmetic implementations in Smalltalk
> and for arithmetic objects in C++.  Look at displaying different shape
> objects on different devices.  Each requires a level of complexity when you
> code them in a message passing style, most of which has to do with the fact
> that you need to dispatch n*m cases through an additional n (or m) methods
> on one or the other classes.

> With multimethods, you can dispatch the m*n cases directly (and quite often
> get code reuse by sharing base cases).  It does simplify things...

I am beginning to suspect that I am inspecting the problem with a less
advanced perspective.. sort of a C++ bias on the whole issue, because I
see the issue as divided between two seperate systems: functional code
and object-oriented stuff.  CLOS I see conbines the two into one system,
where a method is "shared" between the objects it operates on.

The case of arithmetic operations and so forth I consider to be a
functional problem, and not something you typically solve in an
object-oriented fashion, but from a "puristic" object-oriented
perspective, where functions do not exist, only methods, of course CLOS
is a more valuable model, because you are obviously sending to message
to every argument as a sort of "committee" rather than to a single
object you want to affect.  From this perspective the CLOS method makes
a lot more sense.

I'll have to think about this view for a while.


Fri, 26 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS
On Sun, 9 May 1999 18:05:26 GMT,

Bill> CLOS evolved from systems which imposed
Bill> that asymmetry, it dropped that asymmetry in order to gain some very
Bill> useful generality (multiple inheritance), and (as above) it retains
              (You mean 'multiple argument dispatch' here? )

Bill> the ability to describe algorithms which have that asymmetry. So I
Bill> just don't see the problem -- it honestly is a feature, not a bug.

Bill> (Others have pointed out that Bjarne Stroustrup himself has said that
Bill> multiple inheritance is very nice. I'll also point out that Scott

               ^^^^^^^^^^^ (multiple argument dispatch ?)

Bill> Meyers, in _Effective C++_ or _More Effective C++_, I forget which,
Bill> also spends a lot of time showing how to do some of this in C++.  You
Bill> write you could "easily" specialize on the other variables, but I
Bill> actually wouldn't characterize it as all that easy. It's obviously
Bill> doable, but it's also tedious and messy.)

The mail transport agent is not liable for any coffee stains in this message

+44 (0)1223 49 4639                 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax)           | Cambridgeshire CB10 1SD,  GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC  50 3D 1F 64 40 75 FB 53

Fri, 26 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS
On Mon, 10 May 1999 04:00:33 GMT, Kent M Pitman


>Harlequin LispWorks has been producing executables for years.
>It doesn't let you do this in its free version.
>One can hardly blame them.

They could make the executable announce that it's a demo
version built from a demo version of LispWorks.  A crippled
version is a very poor substitute for a full evaluation
version.  Nags, etc., are a much more reasonable way to
prevent commercial use of a demo version than to cripple
the product, because the missing features of a crippled
product prevent a valid evaluation.  To keep the nags from
bothering those who would rather have the crippled version,
the nags can just be put in those features that would have
been missing in the crippled version.

A good example of nags is the latest version of ISE Eiffel,
which can be downloaded from  It's a full
version with all features and no time limit, but with some
nags to make it useless for commercial work.  It does
have more nags than really needed for that purpose.  The
vendors should be careful to strike the right balance in
that kind of thing, because too much nagging can be
annoying and defeat the purpose of trying to get more sales.
ISE Eiffel should only have the one nag when you start an
executable built with the demo version.  All the other nags
should be removed, because they only serve to annoy,
and that one nag in the executable more than does the
job of motivating people to buy ISE Eiffel instead of using
the free version.

Those who prefer C++ over Lisp because they want more
efficient executables might find Eiffel a good compromise.
You also don't have to pay ISE nearly as much money as
you would have to pay one of the major Lisp vendors.  And
the browser in ISE Eiffel is wonderful, once you learn how
to use all its features.  And it's probably a lot easier to
sell your boss on the idea of using Eiffel than Lisp, by
talking about the "design by contract" features, etc.,
and showing how reasonable and efficient the executables

Fri, 26 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

    Joachim> CMUCL indeed provides a lot of the warnings I am looking for, I played
    Joachim> with it last night. Too bad that the commercial implementation I'm
    Joachim> stuck with for now doesn't! :-(

Why not use CMUCL to get the warnings you want and put in the
appropriate declarations?[1]  When your vendor is ready to understand and
make use of declarations, your code will be ready.


[1]  CMUCL does a lot of type inferencing, so using CMUCL to figure
out the needed declarations will probably be close to the minimum
number of declarations needed.

Fri, 26 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

> ...
> As far as I know (though I don't use it myself),
> MCL has been producing executables for many years.

> Harlequin LispWorks has been producing executables for years.
> It doesn't let you do this in its free version.
> One can hardly blame them.

> I suspect that Eclipse CL can produce executables, since the way it works
> it would be hard for it not to.

> I'm pretty sure Corman CL can produce executables.

> I don't know about CLISP or GCL.

CLISP doesn't.

GCL compiles to C, and afaik C produces executables

> ...

Hartmann Schaffer

Fri, 26 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS


> The type declarations I have in mind were of a very different
> kind. The system I am working on is based on a complex,
> object-oriented information model. Functions, mostly generic
> functions, operate on instances of well-defined types from the
> model. Passing an instance of a non-conforming type is almost
> certainly an error.

Unfortunately, I don't think you could even have the sort of type
checking that you want while using GENERIC functions.  Defgeneric syntax
doesn't allow the specification of type restrictions on the input
parameters.  It wouldn't make sense for it to do so, since additional
methods could be added that make the generic function work for
additional type combinations.

This seems to be a case where the flexibility of the language is what
prevents a check from being done at compile time.  Languages like C++
don't have to deal with the possibility of having additional methods or
functions defined after the compilation and link cycle have been

CLOS allows you to later define a method for handling "an instance of a
non-conforming type", thus making it no longer an error.


Fri, 26 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS


> GCL compiles to C, and afaik C produces executables

No, although GCL uses C (and gcc) for it's compilation step (making
it thus not a very fast compiler), it just loads the obtained object
code directly into the Lisp image.  AFAIK, there is no method of
generating "standalone" executables via gcl (i.e. you just dump out
images, like you do with most other Lisps).  That is, the "only"
difference in this regard between GCL and e.g. CMU CL, is that GCL
uses GCC as it's low-level assembler, and it's objects files are
called *.o (+ a couple of other files, IIRC, needed for fixups and
data, since *.o files couldn't hold all the information needed),
whereas CMU CL has it's own assembler, and it's files are called
*.x86f (on IA86 plattforms).

Just because something uses a C compiler somewhere doesn't imply it
will magically fit the C/Unix world-view of an executable.

If you want that, you should take a look at Eclipse or EcoLisp, which
compile to "standalone" C applications (i.e. they are made to fit the
C/Unix world-view).

Regs, Pierre.


  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see]

Fri, 26 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

: > I think it depends somewhat on the problem domain. I've worked a lot on a
: > Lisp program to play the game of Go, a game played on a NxN board,
: > where N is traditionally 19 and the complexity of the game is
: > something {*filter*} (EXPTIME complete maybe?). There are a lot of values
: > which just can't get bigger than N+1 or NxN+1, and it's just never
: > going to overflow a machine word, sorry.

: No need to apologize.  I didn't make the claim this wasn't so.
: The whole point of declarations in the language are to accomodate
: this.  The whole point of programmable access to the language is to make
: sure you don't have to overwhelm your program with declarations.

: > There are large sections of
: > the code which would just work if you told the computer to just use
: > machine word arithmetic,

: And the language provides the ability to do this several ways.
: I'll give examples of two of them here.  Others might involve the
: use of readmacros or code-walking or other such things.

: Using no package surgery but different names:

: (declaim (inline +&))
: (defun +& (x y)
:   (the fixnum (cl:+ (the fixnum x) (the fixnum y))))

: (declaim (inline *&))
: (defun *& (x y)
:   (the fixnum (cl:* (the fixnum x) (the fixnum y))))
: ...etc.

Actually, I don't mind typing out declarations explicitly.  I've heard
other people complain about how declarations are visual clutter that
obscure the core code, but after years of C/C++ I'm used to it, and
besides, with syntax highlighting, it seems like nearly a non-issue.

The problem was that I had to go to considerable trouble to convince
the compiler (CMUCL) that it could safely use fixed-width arithmetic
in the termination tests for loops.

  (DO ((I 0 (1+ I)))
      ((>= I UPPER-LIMIT))

No matter what interval you tell CMUCL that I is in, it can't
prove to itself that (1+ I) is in the same interval.
Mostly these days I declare indices like this to be
of some restricted type like FIXNUM/2


That way, even if CMUCL isn't sure that I hasn't left the interval, at
least it knows it hasn't become a bignum. But it took me a lot of
experimentation before I settled down to this, and it still feels like
a slightly clumsy solution, and in this problem domain, as in others
where you're working with numbers which index into objects which fit
into the machine's memory, that experimentation seems to've been a
deadweight loss for using Lisp: as far as I can tell, it hasn't added
to the reliability or flexibility of this particular program in any
meaningful way compared to just letting the machine use internal,
modulo-wordsize arithmetic arithmetic and not worrying about it.

: > and I put a considerable amount of time into
: > declarations which would let CMUCL prove to itself that everything was
: > OK without type checking, and by and large in retrospect that time was
: > not well spent, in that it didn't help me catch bugs and didn't give
: > me anything I wouldn't have gotten for free by just using machine
: > words.
: I'm not 100% clear about what you're saying here, but would be
: interested if you'd elaborate.  What do you mean "using machine
: words"?

I meant doing what C and C++ do: using the machine's native arithmetic
instructions and hoping either that the programmer doesn't cause
overflow (which is pretty realistic in this problem domain, and some
others) or that the programmer is prepared to deal with overflow if it
happens (which, as you correctly pointed out in the article I was
responding to, is often unrealistic for real programs in problem
domains where overflow is an issue).

: I prefer a Conservative/Libertarian CL, not a Liberal/Socialist one.

That suits me, too.

  Bill Newman

Fri, 26 Oct 2001 03:00:00 GMT  
 [ 350 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

 Relevant Pages 

Powered by phpBB® Forum Software