Reasons for rejecting CLOS 
Author Message
 Reasons for rejecting CLOS

Quote:
> On the other hand, it is my opinion the overloading (specialisation) in
> general is a dangerous practice.  Nobody is perfect, especially not me,
> and I am almost certainly going to define overlapping generics where I
> did not intend to.  Grouping all of the possiblities into one function
> means that there can be no doubt what is being done, and you only have
> to specialise on one variable.  The rest you manually specialise on
> inside the function.

Aren't you saying you are willing to surrender expressive power and
endure the productivity loss of hassling through coding up multiple
dispatches, all because you don't think you can keep your code
straight?  <g>

I am pushing multiple-inheritance and generic functions to the hilt on a
new commercial app. On rare occasions I find myself lost, but a little
navel-staring and consultation of taoist texts always shows me the
light.

Just as with my other programming, I follow certain self-imposed
guidelines to keep my head on straight, including the golden rule, viz.,
that if i can't follow it anymore i have probably made things too hard
and it's time to rethink fundamentally.

You know, I guess I can see the C++ philosophy of "if you can get it to
compile it's probably right" but my taste is for expressive power over
being protected from myself by a dumbed-down language.

I have full respect for anyone who works better under different
circumstances, BTW, but if you want to question Lisp, well, the power vs
save-me-from-myself thing will be coming up an awful lot. Might as well
just flag that as a given.

IMHO,

Ken

PS.

Quote:
> Regardless, I still think of Objective-C as the best object system I
> have ever encountered;

That has interfaces...don't you end doing a lot of cutting and pasting?

KT



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

Quote:



> >> Which object is being operated on in TYPE-INTERSECTION or TYPE-UNION?

> > Both are; these functions should be implemented as functions, not as
> > methods on an object.

> Why? Because they don't have side effects? Surely not; I can't believe
> you would suggest that all accessors should be "functions, not methods"
> (and presumably, as per your next comment, implemented using a COND or
> a CASE!). Because the objects they're working on are immutable? So,
> would your opinion suddenly reverse if the type system changed so that
> the contents of these TYPE objects could legitimately be altered after
> their creation? Because they can make new objects? (Why should that
> make a difference?)

As I mentioned in another post I am starting to see what the meaning of
multiple dispatch is, and why it is useful.

On the other hand, it is my opinion the overloading (specialisation) in
general is a dangerous practice.  Nobody is perfect, especially not me,
and I am almost certainly going to define overlapping generics where I
did not intend to.  Grouping all of the possiblities into one function
means that there can be no doubt what is being done, and you only have
to specialise on one variable.  The rest you manually specialise on
inside the function.

Quote:
> Is it, in fact,
> simply that they involve multiple dispatch and you don't believe in
> multiple dispatch?

I really didn't see what was meant my multiple dispatch, or why it was
useful before, but I think I see now that as an object model it is a
little bit clever.

- Show quoted text -

Quote:
> > > Which of the methods below don't you like?

> > >   (DEFMETHOD TYPE-INTERSECTION ((X MEMBER-TYPE) (Y MEMBER-TYPE))
> > >     ..)

> How do you want them to be implemented, then? Something like this?

>     (defun type-intersection (x y)
>       (cond
>         ((member-type-p x)
>          ...)
>         ((numeric-type-p x)
>          ...)
>         ((enumerated-type-p x)
>          ...)
>         ((structured-type-p x)
>          ...)
>         ...))

> If you really think this is a good way to write code, then I don't
> understand why you're interested in OO at all.

What is type-intersection supposed to do?

I doubt I'd implement it as above, but I don't even know what its for.

Quote:
> This reminds me very strongly of something Erik Naggum once said,
> along the following lines. "Common Lisp doesn't enforce these
> restrictions; you have to be polite. C++ does. The effect is that
> decent people use Common Lisp, whereas thieves and bums use C++".
> I think he exaggerated to make his point, but it is a point even so.

My comment was not about enforcement but rather syntax and appearance,
so you have obviously missed what I was saying.  I have had good
experiences with (now Apple's) OpenStep and Objective-C programming.
Objective-C does not enforce non-access to member variables from
non-member methods, but you will never find an example piece of code
that does so.  It will not give a warning even, if you do it.
Regardless, I still think of Objective-C as the best object system I
have ever encountered; if you have used Objective-C then you might see
how I consider object oriented programming can ideally be done.

CU
Dobes



Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

Quote:


> > Another message has pointed out about 10 lines of code that change
> > functional syntax into message-passing syntax.  Its easy, and so are
> > other changes to make CLOS more object-oriented-ish.

> I'm sorry you took my code as an attempt to `make CLOS more
> object-oriented-ish'.  It wasn't.  It was an attempt to show that
> CLOS's model is a superset of the crippled message-passing /
> single-dispatch idea seems to be all you recognise as object
> oriented.

Yeah, the whole thing clicked for me reading a post by Frank Adrian
earlier, I see now how CLOS is infact object-oriented in a different way
than I see object-orientation.  Your implementation was just more
single-object friendly.

CU
Dobes



Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

Quote:

> On the other hand, it is my opinion the overloading (specialisation)
> in general is a dangerous practice.

First, let us be careful with terminology. In C++ the term
'overloading' refers to a compile-time mechanism where the same
function or method name can be used for what really are different
functions, e.g. instead of

  void munge_A(A *arg);
  void munge_B(B *arg);

C++ allows you to write

  void munge(A *arg);
  void munge(B *arg);

But these functions are not selected based on the runtime type of the
arguments, e.g. if B is a subtype of A:

B b;
A *a = &b;
munge(a);  // calls munge(A *) !!!

Multiple dispatch in CLOS selects methods based on the dynamic,
runtime type of arguments, which in C++ is only supported for a single
argument: the target of virtual functions. So, to avoid confusion let
us talk about method specialization in CLOS, not overloading.

Quote:
> Nobody is perfect, especially not me, and I am almost certainly
> going to define overlapping generics where I did not intend to.
> Grouping all of the possiblities into one function means that there
> can be no doubt what is being done, and you only have to specialise
> on one variable.  The rest you manually specialise on inside the
> function.

This is not really true if you think about it. Take the binary
operator example. Say you start with a method for the most general
type, say number-class. Then you add a subtype integer-class, and you
may want to specialize the integer-class case with a more efficient
method.

(defmethod binop ((left number-class) (right number-class)) ...)
(defmethod binop ((left integer-class) (right integer-class)) ...)

You still want to use the general method for mixed combinations of
arguments. In CLOS, the more general method will be called
automatically unless BOTH arguments are of type integer-class, and the
specialized method will only be called for the case it is designed
for, namely when both arguments are of type integer-class. In C++ the
binop methods on both classes must be able to deal with the mixed
case! Not all possibilities are in the same function!

Quote:
> > How do you want them to be implemented, then? Something like this?

> >     (defun type-intersection (x y)
> >       (cond
> >         ((member-type-p x)
> >          ...)
> >         ((numeric-type-p x)
> >          ...)
> >         ((enumerated-type-p x)
> >          ...)
> >         ((structured-type-p x)
> >          ...)
> >         ...))

> > If you really think this is a good way to write code, then I don't
> > understand why you're interested in OO at all.

> What is type-intersection supposed to do?

The point being made here is that lack of multiple dispatch in C++
forces you sometimes into using switch statements, a technique which
was supposed to have been replaced by virtual function calls.

Joachim

--




Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS


Quote:
>In languages like C++, where (operator) overloading is "allowed", you
>might implement both string concatenization and integer addition with
>an operator +.  While this would be possible to do in CL by accident
>(since both operations have the same arity), it is wrong, since both
>operations are arguably semantically different.

"Arguably" is the key word there.  Most of us learned to add
by putting apples together.  Here are 3 apples, here are two
more, how many do we have?  Putting strings together is a
similar operation.  Here is a short string, here is another,
what do we have?  Of all the possible interpretations of
string addition, concatenation is in fact that one that
most appeals to common sense, and is in fact the best
usage of the addition operator with strings, unless you
already have another concatenation operator, in which
case it's better to reject the addition operator as an
error.  But in C++ there is no standard string concatenation
operator, and the choice of '+' is common and generally
accepted.


Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

Quote:



> >In languages like C++, where (operator) overloading is "allowed", you
> >might implement both string concatenization and integer addition with
> >an operator +.  While this would be possible to do in CL by accident
> >(since both operations have the same arity), it is wrong, since both
> >operations are arguably semantically different.

[snip]

Quote:
> Of all the possible interpretations of
> string addition, concatenation is in fact that one that
> most appeals to common sense,

me, you may not be disagreeing with him.

I liked what he said because "+" as an alias for string concatenation
requires poetic license. If you mean 'concatenate', why not say
concatenate? You do not seem to dispute that a bit of metaphor is
required to get concatenation out of "+".

BTW, the interpretation of string addition that most appeals to my
common sense is "123" + "456" => "579", with an error for "hello, " +
"world".

Ken



Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

Quote:



> > But hey, it's free software... except RedHat charges $50 per
> > tech-supported license and I hear only has robots on tech-support duty
> > and replying to emails.

> The Red Hat support "entity" with which I recently interacted by email
> behaved like a human being. If it was a robot, I'd like to see its source
> code :-)

I've been hearing for awhile now how the've intended to invest the
$20M they got from Intel and others primarily to improve their tech
support. So maybe things are starting to get better....

Christopher



Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

Quote:



> >In languages like C++, where (operator) overloading is "allowed", you
> >might implement both string concatenization and integer addition with
> >an operator +.  While this would be possible to do in CL by accident
> >(since both operations have the same arity), it is wrong, since both
> >operations are arguably semantically different.

> "Arguably" is the key word there.  Most of us learned to add
> by putting apples together.  Here are 3 apples, here are two
> more, how many do we have?

5.

Quote:
> Putting strings together is a similar operation.  Here is a short
> string, here is another, what do we have?

2 strings.

Quote:
> Of all the possible interpretations of string addition,
> concatenation is in fact that one that most appeals to common sense

If you walk into a first-grade classroom and ask, "what do you get
when you add an "apple" and 3", what kind of answers do you think you
would get? They would probably think in terms of placing an apple
object and a 3 object into a container like a basket, the 3 object
represented by something like a cardboard cutout of a "3".

Apparently in Java it would be "apple3". But with Java I find this
acceptable because the alternative is to use the ugly and less
readable C function syntax. I think using "+" this way in Lisp is
particularly unsafe, and particularly ugly and useless.

Christopher



Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS
The really important reason not to allow + to be overloaded as it is
in Java is the way is that identities like x+y-y = x are not useful to
the compiler when you have "inconsistencies" around such as you have
for + because there is no general rule about what a good definition
is.

Java may be able to define a + operator to do string concat, but a -
operator is a lot more problematic.  Even if you could make "foobar" -
"bar" yield "foo", the problem is that commutativity and associativity
doesn't work.  x-y+y is not the same as x+y-y, for example, because...
well, it's hopefully not worth belaboring.



Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

Quote:
> Historical note:  An earlier OO system for Lisp (FLAVORS), was very much
>    based on the message passing paradigm.  It even used SEND to send
>    messages to a single distinguished object.

> I wonder if Kent Pitman or someone else would care to comment on some of
> the background that went into deciding to use the CLOS/generic function
> model rather than the object/message passing model for the Common Lisp
> object system?

Multimethods were an influence of Xerox.  We had locked out the Xerox
crowd when we made CL, because CL was historically a defensive ploy to
keep Interlisp from killing the Maclisp community.  Interlisp was,
lamentably, pretty much wiped out in the process of making CL.  But
the Xerox crowd came to the table at the start of X3J13 (1986-1988)
with one of four full proposals for an object system.  Discussions
were had about which way to go and what resulted was a kind of hybrid
of something called LOOPS (from Xerox) and Flavors (from Lisp
Machines).  Among the various influences of LOOPS (not to be confused
with LOOP, btw) one of the most prominent was multimethod dispatching.
The Maclisp/LispM community had never had this and questioned whether
it was ever useful.  The Xerox guys insisted we only had never wanted
it because we didn't have it as an option of using it.  In retrospect,
I think they were clearly right.

I don't know if that helps at all.  There is probably more that could be
said, but it's too late at night for me to remember much else.
'nite.



Sat, 27 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

        ...

Quote:

> You lose the power to accept command-line parameters and similar, but
> thats not a huge loss.  Unfortunately the interface to do so is a little
> difficult to use properly, there are a few options and so forth.. I
> imagine you could figure it out and use it fairly easily after some
> practice and research.

Command Line parameters...... on a Mac?

Do you realize that Java specifies that programs such as

        public class IAmNotPortable {
          public static void main(String[] args) {
            ...
          }
        }

are not portable?

Cheers

--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa



Sat, 27 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