Reasons for rejecting CLOS 
Author Message
 Reasons for rejecting CLOS



Quote:
>[ replying to comp.lang.lisp only
>   http://www.*-*-*.com/ ~pitman/pfaq/cross-posting.html ]

>I know it's all most too much to hope for, but I nevertheless wish
>this discussion will be moved off of comp.lang.lisp.

>If people want to debate the merits of a good AI language, then I think
>comp.ai is adequate for that.  Indeed, questions about what the "right
>language" is are always best answered in a forum appropriate to the need.
>See my pfaq entry above for a longer-winded explanation of why I think
>it's a bad idea to drag down comp.lang.lisp in this discussion.

>If this were a comp.lang.lisp-only discussion, there are things I would say
>relevant to this topic, but I don't want to get involved in some vast
>multi-forum flamefest whose purpose seems more to consume resources than
>to hear a coherent answer.

>JMO.

This IS a comp.lang.lisp only discussion now.  comp.ai just became
moderated and for now they will not accept ANY cross posted messages.
Also unless the problem is restated in some way I'm sure that the
comp.ai moderators would not allow this discussion back.

Joshua Scholar



Sun, 28 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS
OOOOOOOOOOOOPs

I responded to a very old message with realizing it.  Sorry.

Joshua Scholar



Sun, 28 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS


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

But Java is statically typed, so the compiler can perfectly well distinguish
the cases where "+" has all the properties you are talking about.  Or am I
missing something?

-- Harley



Sun, 28 Oct 2001 03:00:00 GMT  
 Reasons for rejecting CLOS

Quote:



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

> But Java is statically typed, so the compiler can perfectly well distinguish
> the cases where "+" has all the properties you are talking about.  Or am I
> missing something?

Well, my points were several.  One is that you do have to statically type
the language in order to be able to manage the identities since otherwise
different identities apply depending on the values and you can't do any
optimization.  Another is that even in the presence of typing, it is possible
to scroll your screen so the type declarations are out of sight and it's still
possible to look at a certain piece of code in isolation that is hard to
understand.  Yet another is that I guess I find it kind of visually gross
to see the arg signature be totally varied in ways that vary not only according
to use, but are kind of huffman-encoded in terms of knowing that certain args
being what they are tells you additional syntaxes are available that wouldn't
be if you used different args.  These are all just personal preferences on
my part, not absolutes.  But they are strong personal preferences.

I think the right way to "support" (and I use the term loosely) the
idea of people wanting to overload operators is to let them define the
operator in a different namespace (whether package or lexical module)
if they want to give it incompatible meaning.  But within any given
namespace, I'd like a given operator to have one purpose.  Otherwise,
I personally don't get enough "mileage" out of having given the thing
a name, since the "name" doesn't really act as a mark of quality in
any context--the name could do anything at any time and any name could
just be waiting to surprise me.  It sounds like it would work against
macros, for example.  (I have no experience that I can recall offhand
with macros in strongly typed languages, though, so I'm not sure what
that would look like...)



Sun, 28 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