Python syntax in Lisp and Scheme

Dirk Thierbach dthierbach at gmx.de
Wed Oct 8 05:58:54 EDT 2003


james anderson <james.anderson at setf.de> wrote:

>> > is the[re] no advantage to being able to do either - or both - as the
>> > occasion dictates?

Of course it's good to be able to do either. And Lisp macros are a 
powerful tool, and it's good to have it when you need it. But it's 
somewhat annoying to frequently read grossly exaggerated claims like
"lots of things you can do with Lisp macros are impossible to do in
any other language" when you can do a good part of these things even in
Lisp without macros.

>> The interesting part is that most Lisp'ers don't seem
>> to use them, or even to know that you can use them, and use macros instead.

> while the first assertion might well be born out by a statistical
> analysis of, for example, open-source code, i'm curious how one
> reaches the second conclusion.

I don't have statistical evidence, this is just my personal
impression.  On the one hand, there are the above claims, on the other
hand, I see code that would (IMHO) much more simple and elegant with
HOFs, but instead imperative assignment is used, or macros. So I then
I have the impression that the programmer doesn't really know how to
use HOFs, otherwise he would have used them. Maybe that's wrong and
they all do that on purpose, or because they don't like HOFs (like you
seem to do), but somehow this is difficult to imagine.

>> The advantage of HOFs over macros is simplicity: You don't need additional
>> language constructs

> when did common-lisp macros become an "additional language construct"?

It's "additional" in the sense that you can write programs without it,
and that different Lisp dialects use a different syntax and semantics 
for macros. HOFs on the other hand are pure lambda calculus, and every
functional language has them.

>>     (which may be different even for different Lisp
>> dialects, say), and other tools (like type checking) are available for
>> free; and the programmer doesn't need to learn an additional concept.

> doesn't that last phrase contradict the previous one?

I don't see any contradiction; maybe you can be more explicit?

> i do admit to infrequent direct use of higher-order functions. one
> reason is that there is little advantage to articulating the
> creation of functions which have dynamic extent only,

Why? The whole point (or one of them) of functional languages is that
functions are first class, and you can easily use them (and you
frequently do) in 'map', 'fold', or more complicated HOFs. It's simple,
elegant, reusable, type-safe, and avoids unecessary state. A definition
like

  sum = foldr (+) 0

in Haskell is a lot better than doing an explicit loop. If you don't
use HOFs at all, then IMHO you're not doing proper functional
programming.

> so in my use, most hof's are manifest through a macro
> interface. it's the same distaste i have about inner and anonymous
> java classes.

I don't like inner and anonymous classes either: They're just a clumsy
substitute for anonymous functions, and they have too much syntactic 
garbage associated with them.

> the other reason is that when i moved from scheme to lisp, in the
> process of porting the code which i carried over, it occurred to me
> that much of what i was using higher-order functions for could be
> expressed more clearly with abstract classes and appropriately
> defined generic function method combinations.

Sometimes it is more convenient to use other forms of parametrization
(like classes). Sometimes HOFs are more natural. It really depends on
the concrete example. And of course 'classes' or similar language
features are independent from macros, and many languages provide them,
even if they don't have macros.

- Dirk




More information about the Python-list mailing list