[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Overloading of primitive operators
- To: Nat Ballou <ballou@ernest.aca.mcc.com>
- Subject: Re: Overloading of primitive operators
- From: kanderso@DINO.BBN.COM
- Date: Thu, 15 Mar 90 21:58:25 -0500
- Cc: CommonLoops.pa@Xerox.COM
- In-reply-to: Your message of Tue, 13 Mar 90 14:15:00 -0600. <19900313201554.9.BALLOU@LILITH.ACA.MCC.COM>
- Redistributed: CommonLoops.pa
Redistributed: CommonLoops.pa
Date: Tue, 13 Mar 90 14:15 CST
From: Nat Ballou <ballou@ernest.aca.mcc.com>
Subject: Overloading of primitive operators
To: CommonLoops.pa@xerox.com
Postal-Address: 3500 West Balcones Ctr. Dr., Austin, TX 78759
Phone: (512) 338-3376
One (of the few?) advantage(s) that C++ holds over CLOS is the
ability to overload the primitive operators in C. For example, C++
allows one to overload the equivalent Common Lisp operators eq,
aref, not, +, -, *, /, mod, >, <, etc. I am under the impression
that ANSI Common Lisp (with CLOS) will not allow such operators to
be overloaded. Is this correct? If so, why?
I believe this is correct. I presume one reason why is to allow
current implementations of LISP to remain relatively efficient,
without a lot of work. For example, functions like EQ, NOT, and CAR,
are inline coded for speed. If everything became generic overnight,
LISP would be a lot slower until we added a lot of type information,
and got better at type deduction.
I believe C++'s overloading is more like pattern matching on types of
operands at compile time, rather than generic function dispatch. This
lets C++ do a lot of inlining.
I hope that over time, LISP will become more completely object
oriented, since this would allow efficiencies that currently aren't
possible (inline method dispatch for example). This plus good
compiler optimizations could make a very high performance LISP.
k