Python syntax in Lisp and Scheme

james anderson james.anderson at setf.de
Thu Oct 9 05:56:48 EDT 2003


Matthias wrote:
> 
> cstacy at dtpq.com (Christopher C. Stacy) writes:
> 
> > He probably means "operator overloading" -- in languages where
> > there is a difference between built-in operators and functions,
> > their OOP features let them put methods on things like "+".
> > [...]
> > And in Lisp if you want to do some
> > other kind of arithmetic, you must make up your names for those
> > operators.  This is considered to be a good feature.
> 
> In comp.lang.lisp there was recently a thread discussing why not all
> CL-types were also CL-classes and all functions CLOS-methods (so that
> operator overloading would be possible).  I think the outcome was more
> or less "it happened by historic accident and it's easier to write
> fast compilers then".

that is not an accurate restatement of the conclusion which i recall. i
suggest that more accurate summary would be:

1. should one need operators which "look" like the standard operators, but
which have a different defined semantics, one places their names in a package
which is isolated from :common-lisp, and either codes with reference to that
package or exports them from that package and codes with reference to a
package which inherits those symbols in preference to those exported from the
:common-lisp package.

2. one does not want to specialize the standard operators other than in the
ways which the standard permits, as not only other applications, but also the
implementation itself may depend on that they have the semantics which the
standard specifies.


>    In general, taking away flexibility from the
> programmer is not in the spirit of Lisp, though.

one might argue, that the standard should have specified that a conforming
implementation not depend on the definitions named by symbols in the
:common-lisp package itself, but instead use it's internal functions. in order
to be convincing, the argument would need to identify use cases which option
(1.) does not support.

one can even rename the :common-lisp package and provide their one. one should
not, however, expect all programs to tolerate such a change.

...




More information about the Python-list mailing list