Paul Rubin:
> [EMAIL PROTECTED] writes:
>> <about Scheme macros>
> It wasn't obvious how to do it in Scheme either. There was quite
> a bit of head scratching and experimental implementation before
> there was consensus.
Actually I am not convinced there is consensus yet, i.e. there is a
non-negligible minority of schemers convinced that original Lisp
macros where better, not to talk of common lispers ;)
>> 3. We would add to Python the learning curve of macros and their
>> subtilities and we do not want it.
> I can't imagine how it could be worse than the learning curve of
> __metaclass__, which we already have.
To me, learning macros *and their subtilities* was much more difficult
than learning metaclasses.
>> 4. Macros would complicate a lot Python module system.
> I don't see how, but maybe I'm missing something.
Go to comp.lang.scheme and google for "macros and module system";
you will get everything you want to know and much more!
>> 5. We have Guido providing a good syntax for us all, why we should
be
>> fiddling with it? More seriously, if some verbosity is recognized
>> in the language (think to the "raison d'etre" of decorators, for
>> instance) I very much prefer to wait for Guido to take care of
>> that, once and for all, than having 100 different custom made
>> solutions based on macros.
> Every time some newbie asks an innocent "how do I ..." question, we
> see unbelievably horrid answers from gurus. Just check the FAQ about
> conditional expressions, etc. I just don't see Python syntax changes
> as forthcoming.
Well, I see this as a positive fact. If a syntax is contrived (such as
a ternary
operator, for instance) it is better *not* to have it than to have one
hundred custom
made syntaxes. At the end, we are just talking about syntax sugar here,
not about
lack of functionality.
>> What I would be interested in is a Lisp/Scheme implementation
>> compiling to Python bytecode, but I am not aware of any project
>> in that direction.
> But that sounds like a bizarre idea. Python bytecode is just a
> CPython artifact, not part of the language. And it's not even that
> good an artifact. Good Lisp/Scheme implementations compile to native
> code that beats the pants off of CPython bytecode. It would make much
> more sense to have a Python implementation that compiles Python to
> S-expressions and then lets a high performance Lisp or Scheme system
> take care of the rest.
This is a bizarre idea if you want to make Python run faster. It is not
so bizarre
if what you want is to have access to Python from Lisp/Scheme in the
same sense
Jython has access to Java.
Michele Simionato
--
http://mail.python.org/mailman/listinfo/python-list
