On Jun 13, 2006, at 9:00 PM, Shane Hathaway wrote:
People long for macros in Python. I think Guido shies away from macro
adoption because it could easily lead to a rapid divergence in code
styles, making it difficult to maintain the level of interoperability
Python currently has. Do macros reduce interoperability? If two
programmers use a different set of macros, can they join their code?
Can you generally pick up a random bit of Lisp code and use it in your
application, like you can in Python?
More or less, yes. Think of it this way; instead of libraries only
providing functions, with macros they can also provide new langage-
level abstractions. Sometimes they will significantly change the
style of the code that uses them, and sometimes they won't.
Changing the basics of Lisp just because it's possible is discouraged
just for this reason. It's certainly possible, but it's not all that
common.
Most recent Python language proposals could be implemented with
macros.
I think Guido prefers to be the shepherd of all code at that
level. A
few dedicated hackers manage to implement macro-like functionality
with
decorators.
Python has a very strong philosophy of guiding its programmers in the
manner in which they should write their programs. This philosophy is
great for the readability of python programs, but it limits the
flexibility of the language. It's a tradeoff, and lisp is on the
other side of it. Both sides have their benefits, though.
Scheme, for example, has a semi-formal process by which new language
features can be proposed. They're almost always implemented via
macros as part of the proposal, so scheme implementations can choose
to support them. You can then note which SRFIs are required for your
code and keep it portable to any Scheme system that supports those
features.
Common Lisp doesn't really have a strong system like that, but it has
a much richer standard library already such that it's not really
necessary. Most macros tend to be written in support of a specific
application rather than a general library; otherwise, they are part
of a fairly portable library that can be imported to make use of
those features.
Python can do this too, although people generally avoid it because
restarting the process has more predictable effects.
That's one of the things I like about python when I use it. It's not
quite the same feel as lisp, though, because there aren't really any
tools (at least that I'm aware of) that support using python that
way. There used to be more for Lisp; the Lisp Machines were a prime
example. Once the Lisp system booted up, you would essentially be
modifying the runtime environment on the fly by recompiling bits of
it as you went and patching them into the live system. It's a
different way of working than the edit/compile/run cycle of C-style
language development. Smalltalk systems like Squeak still work that
way. SLIME, a program for emacs and Common Lisp, creates a kind of
interactive environment that weakly resembles the Lisp Machine form
of interaction, and work on McCLIM (a user interface abstraction
layer) and applications for it may eventually make a Lisp Machine-
style environment usable again.
Anyway, as I said, lisp has been around for a long time and has been
pretty well picked over, and pieces of it exist everywhere, even in
C. Visual Basic.net now has some abilities to do abstract syntax
tree rewriting as part of the LINQ system, for goodness sake. :)
Lisp is not just the sum of those features, though; it's got a unique
feel that emerges as a consequence of its history, its features, its
implementations, and the code libraries and resources that are
available.
--Levi
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
