Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

"Terry Reedy" <tjreedy at udel.edu> writes:

> "Douglas Alan" <doug at alum.mit.edu> wrote in message 

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

> Anyone can write modules, experimental or otherwise, without touching the 
> code base for any particular implementation.

> For those whose know one of the implementation languages, source code 
> control systems allow one to do experiments on branches without 'sullying' 
> the trunk or impeding the development thereof.

When I said "without having to sully the code base", I meant that one
can implement a language feature for the target language as a loadable
module written entirely within the language itself, and without having
to understand anything particularly deep or specific about the language
implementation details.

I.e., I could write a new object system for Lisp faster than I could
even begin to fathom the internal of CPython.  Not only that, I have
absolutely no desire to spend my valuable free time writing C code.
I'd much rather be hacking in Python, thank you very much.

> One of the goals of the PyPy project was to allow people to experiment with 
> syntax extensions in Python itself.  (But I don't know how easy that is 
> yet.)

PyPy sounds like a very interesting project indeed!

> But I think that overall the problem of designing new syntax is more
> in the design than the implementation.  Anything new has to be
> usable, readable, not clash too much with existing style, not
> introduce ambiguities, and not move the extended language outside
> the LL(1) [I believe that is right] subset of CFLs.

People (myself included) haven't had much trouble implementing nice
and useful macro packages for Lisp.  Admittedly, it's a harder problem
for a language that doesn't have a Lisp-like syntax.  I believe that
Dylan has macros without having a Lisp-like syntax, but Dylan is
really a dialect of Lisp, only with a more traditional Algol-like
syntax veneered onto it.  My guess is that a macro developer for Dylan
would have to be familiar with an underlying hidden intermediate Lisp
syntax.  (Though I'm just really just spouting that guess out of my
butt.)

A few years back, I designed a somewhat Python-like language with a
macro facility for a class on dynamic languages and their
implementations.  I didn't implement it, however, and I doubt that
I'll have time to get around to it in this lifetime.

|>oug