Python syntax in Lisp and Scheme

[james anderson]

Dirk Thierbach wrote:
> 
> james anderson <james.anderson at setf.de> wrote:
> > Matthias Blume wrote:
> 
> >> Most of the things that macros can do can be done with HOFs with just
> >> as little source code duplication as with macros.  (And with macros
> >> only the source code does not get duplicated, the same not being true
> >> for compiled code.  With HOFs even executable code duplication is
> >> often avoided -- depending on compiler technology.)
> 
> > is the no advantage to being able to do either - or both - as the
> > occasion dictates?
> 
> I can't parse this sentence,

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


>    but of course you can also use HOFs in Lisp
> (all flavours). 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.

> The only real advantage of macros over HOFs is that macros are guaranteed
> to to executed at compile time. A good optimizing compiler (like GHC
> for Haskell) might actually also evaluate some expressions including
> HOFs at compile time, but you have no control over that.
> 
> > i'd be interested to read examples of things which are better done
> > with HOF features which are not available in CL.
> 
> HOFs can of course be used directly in CL, and you can use macros to
> do everything one could use HOFs for (if you really want).

that's a disappointment.

> 
> 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"?

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

...