[OT] Lisp's "and more", was Re: Who modified my local variable?

Levi Pearson levi at cold.org
Tue Jun 13 21:41:31 MDT 2006

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  

> 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  

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  


More information about the PLUG mailing list