Steven D'Aprano <[EMAIL PROTECTED]> writes:
> On Wed, 20 Jun 2007 17:23:42 -0400, Douglas Alan wrote:
>> Macros are a way to abstract syntax the way that objects are used to
>> abstract data types and that iterators and generators abstract control,
>> etc.
> But why is the ability to abstract syntax good?
It allows the community to develop language features in a modular way
without having to sully the code base for the language itself. A
prime example of this is how CLOS, the Common Lisp Object System was
implemented completely as a loadable library (with the help of many
macros) into Common Lisp, which was not an OO language prior to the
adoption of CLOS.
The fact that CLOS could be developed in a modular way allowed for a
number of different groups to work on competing object systems. After
some experience with the pros and cons of the various object systems,
the developers of CLOS were able to incorporate most of the best ideas
from the entire field and then get it adopted as a defacto standard.
This allowed, for instance, the inclusion of multimethods, which are
an extremely nice feature for modular code development. In prior Lisp
dialects I had used, the object systems were more like the
single-object dispatching OO system in Python, which is substantially
inferior. The fact that the entire OO system in Common Lisp could be
loaded as a module that is coded entirely within Common Lisp allowed
for a large jump in the quality of its OO subsystem.
> One criticism of operator overloading is that when you see X + Y you
> have no real idea of whether it is adding X and Y together, or doing
> something bizarre.
Yes, and despite this, operator overloading is an essential feature
for a modern language. (Java's lack of it notwithstanding.)
> Now allow syntax to be over-ridden as well, and not only can't you tell
> what X + Y does, but you can't even tell what it *means*. Maybe its a for-
> loop, calling the function Y X times.
(1) With operator overloading you have no idea what X + Y *means*. It
could be feeding the cat, for all you know. If that turns out to
be the case, you fire the programmer in question. Just because a
language feature *can* be abused is no reason to leave it out of a
language. Power always comes with responsibility, but we still
need powerful programming languages.
(2) In Lisp, you cannot redefine existing syntax (without modifying
the standard library, which would be considered very rude), so the
problem that you are talking about is moot. You can only add
*new* syntactic constructs. I would suggest that any proposed
syntax extension mechanisms for other languages behave like Lisp
in this regard.
> Sometimes, more freedom is not better. If you had a language that
> let you redefine the literal 1 to mean the integer zero, wouldn't
> that make it much harder to understand what even basic arithmetic
> meant?
But we're not talking about anything like this. E.g., in some
dialects of Lisp it used to be possible to set the variable that
contained the value for *true* to the value for *false*. If you
actually did this, however, just imagine the havoc that it would
wreak. So ultimately, this capability was removed.
Alas, in Python, you can still do such a crazy thing!
> But that doesn't mean I want a language where anything goes
You are imagining something very different from what is proposed.
Lisp-like macros don't allow "anything goes".
|>oug
--
http://mail.python.org/mailman/listinfo/python-list
