From: Knut Olav Bøhmer
Subject: anamorphic macros
Date: 
Message-ID: <1JGee.9273$SL4.210961@news4.e.nsc.no>
Hi,

Some people don't like anamorphic macros. I need help to understand why
anamorphic macros is not a good thing. As I have most of my programming
experience in perl, you can understand that it's difficult for me to
understand (If you know perl).

Maybe there exists some situations I haven't thought about, where
anamorphic macros are something I should really avoid.

-- 
Knut Olav B�hmer

From: Pascal Costanza
Subject: Re: anamorphic macros
Date: 
Message-ID: <3e0uokFk1iaU1@individual.net>
Knut Olav B�hmer wrote:

> Hi,
> 
> Some people don't like anamorphic macros. I need help to understand why
> anamorphic macros is not a good thing. As I have most of my programming
> experience in perl, you can understand that it's difficult for me to
> understand (If you know perl).
> 
> Maybe there exists some situations I haven't thought about, where
> anamorphic macros are something I should really avoid.

If an anaphoric macro creates a binding with a default name, you may get 
conflicts when you nest two uses of that macro. Simple example:

(defmacro awhen (expr &body body)
   `(let ((it ,expr))
      (when it ,@body)))

(awhen (+ 1 2)
   (awhen (* 3 4)
     (print it)))

This prints 12 because IT refers to the inner binding. There is no way 
in the inner code to refer to the outer IT anymore.

This is especially bad when it's not obvious that there is an inner binding:

(defmacro bla (&body body)
   `(awhen (* 3 4) ,@body))

(awhen (+ 1 2)
   (bla (print it)))

Here, IT refers to the binding of an inner AWHEN, but you wouldn't know 
if you don't know the implementation details of the BLA macro.

Therefore it's better to let the user decide what name to use:

(defmacro when-let ((var expr) &body body)
   `(let ((,var ,expr))
      (when ,var
        ,@body)))

(when-let (outer (+ 1 2))
   (when-let (inner (* 3 4))
     (print outer)
     (print inner)))


A corollary is that your own macros shouldn't expand into anaphoric 
macros (don't write something like the BLA macro above), but that 
anaphoric should only be used in "user-level" code.


Pascal

-- 
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
From: Knut Olav Bøhmer
Subject: Re: anamorphic macros
Date: 
Message-ID: <cRIee.8889$ai7.217549@news2.e.nsc.no>
Pascal Costanza wrote:
> Knut Olav B�hmer wrote:
> 
>> Hi,
>>
>> Some people don't like anamorphic macros. I need help to understand why
>> anamorphic macros is not a good thing. As I have most of my programming
>> experience in perl, you can understand that it's difficult for me to
>> understand (If you know perl).
<-cut->
> 
> (defmacro when-let ((var expr) &body body)
>   `(let ((,var ,expr))
>      (when ,var
>        ,@body)))
> 
> (when-let (outer (+ 1 2))
>   (when-let (inner (* 3 4))
>     (print outer)
>     (print inner)))
> 
> 
> A corollary is that your own macros shouldn't expand into anaphoric
> macros (don't write something like the BLA macro above), but that
> anaphoric should only be used in "user-level" code.

Thanks. When-let really is all we need. I have actually thought about it.

-- 
Knut Olav B�hmer
From: Frode Vatvedt Fjeld
Subject: Re: anamorphic macros
Date: 
Message-ID: <2hzmv81qhe.fsf@vserver.cs.uit.no>
Pascal Costanza <··@p-cos.net> writes:

> A corollary is that your own macros shouldn't expand into anaphoric
> macros (don't write something like the BLA macro above), but that
> anaphoric should only be used in "user-level" code.

I like to call it "surface syntax", the operators that are unfit to
build macros over. Of the standard operators, I count loop as surface
syntax.

-- 
Frode Vatvedt Fjeld
From: Tron3k
Subject: Re: anamorphic macros
Date: 
Message-ID: <1115438894.255113.259440@g14g2000cwa.googlegroups.com>
Hi, I'm wondering why Loop is unfit for use in macros. If so, I might
have some troubles. =)

Tron3k
From: Steven M. Haflich
Subject: Re: anamorphic macros
Date: 
Message-ID: <tcYee.3710$5o2.3380@newssvr13.news.prodigy.com>
Tron3k wrote:
> Hi, I'm wondering why Loop is unfit for use in macros. If so, I might
> have some troubles. =)

I think Frode may be prejusiced against loop.  Acceptance of loop
is something of a religious issue among Lisp programmers.  It is
counterproductive to argue about it, but I'll go just this far:
It is certainly possible that a buggy loop implementation could
expand into code that has pathological anamorphicisms, but I see
no way in which these problems would be fundamental to the
semantics of loop.  Rather, they would be considered bugs.

The closest thing I've seen to a common anamorphicism problem in
loop is that loop expands into a block that by default is names
nil.  Nil is a symbol exported from the cl package, and therefore
use of loop inside the expansion of some iteration macro may
promiscuously block [sic -- a pun!] some inner return-from.  A
quick example (untested):

(defmacro dolist-by-cddr ((var list &optional retform) &body body)
   (let ((x (gensym))
     `(loop for x on ,list by #'cddr
         as ,var = (car ,x)
         do ,@body
         finally (return ,retform))))

Now, if someone used this macro this way

   (dolist (x my-caches)
     (dolist-by-cdr (y x)
       ...
       (when mumbl (return nil))
       ...))

the return-from would incorrectly return from the nil-named block in
the loop inserted by dolist-by-cddr.

The fix for this is either to document clearly that dolist-by-cddr
inserts a nil-named block (lisk the other standard do-mumbl macros)
or else to add a
   named ,(gensym)
clause to the dolist-by-cddr expansion.  More oftent than not
programmers forget to do one or the other.  When they do, and when
a user programmer happens to use a return in the body, it can be
a difficult bug to diagnose.
From: Kalle Olavi Niemitalo
Subject: Re: anamorphic macros
Date: 
Message-ID: <871x8j73hb.fsf@Astalo.kon.iki.fi>
"Steven M. Haflich" <···@alum.mit.edu> writes:

> The fix for this is either to document clearly that dolist-by-cddr
> inserts a nil-named block (lisk the other standard do-mumbl macros)
> or else to add a
>    named ,(gensym)
> clause to the dolist-by-cddr expansion.

But that doesn't help against LOOP-FINISH.

(loop for x in my-caches
  (dolist-by-cddr (y x)
    ...
    (when mumbl (loop-finish))
    ...))

So you must instead write:

(defmacro dolist-by-cddr ((var list &optional retform) &body body)
  (check-type var symbol) ; See the question below.
  (let ((body-name (gensym))
        (rest-name (gensym)))
    `(flet ((,body-name (,var)
               ,@body)) ; The body can declare ,var special.
       (loop for ,rest-name on ,list by #'cddr ; This loop need not be named.
             do (,body-name (car ,rest-name)))
       (let (,var)
         ,retform))))

Or extend the LOOP macro to make its uses hideable from plain (loop-finish).
<http://www.cliki.net/Proposed%20Extensions%20To%20ANSI>

BTW, what do you think about this use of CHECK-TYPE?  It seems
somewhat suspicious to me, because STORE-VALUE cannot correct the
macro form from which the parameter was originally extracted.
From: Thomas F. Burdick
Subject: Re: anamorphic macros
Date: 
Message-ID: <xcvbr7k92bb.fsf@conquest.OCF.Berkeley.EDU>
Kalle Olavi Niemitalo <···@iki.fi> writes:

> "Steven M. Haflich" <···@alum.mit.edu> writes:
> 
> > The fix for this is either to document clearly that dolist-by-cddr
> > inserts a nil-named block (lisk the other standard do-mumbl macros)
> > or else to add a
> >    named ,(gensym)
> > clause to the dolist-by-cddr expansion.
> 
> But that doesn't help against LOOP-FINISH.

Rather than all of this, here's what I do if I want a macro to expand
into a LOOP:

  * Name the macro LOOP-THING, rather than DO-THING, indicating to the
    user that it expands in terms of LOOP.

or

  * Wrap the body in an flet, like this:

> So you must instead write:
> 
> (defmacro dolist-by-cddr ((var list &optional retform) &body body)
>   (check-type var symbol) ; See the question below.
>   (let ((body-name (gensym))
>         (rest-name (gensym)))
>     `(flet ((,body-name (,var)
>                ,@body)) ; The body can declare ,var special.
>        (loop for ,rest-name on ,list by #'cddr ; This loop need not be named.
>              do (,body-name (car ,rest-name)))
>        (let (,var)
>          ,retform))))

But yuck, what's with all the gensyms?!?!  The whole point of lifting
the body of the code is to insulate it from the LOOP's lexical
environment:

  (defmacro dolist-by-cddr ((var list &optional retform) &body body)
    `(let ((body (lambda (,var) ,@body))
           (retval (lambda (,var) ,@retform))
           (list ,list))
       (loop for elt in list by #'cddr
             do (body elt)
             finally (return (retval nil)))))
From: Peter Seibel
Subject: Re: anamorphic macros
Date: 
Message-ID: <m3sm0w9uhw.fsf@gigamonkeys.com>
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> But yuck, what's with all the gensyms?!?!  The whole point of lifting
> the body of the code is to insulate it from the LOOP's lexical
> environment:
>
>   (defmacro dolist-by-cddr ((var list &optional retform) &body body)
>     `(let ((body (lambda (,var) ,@body))
>            (retval (lambda (,var) ,@retform))
>            (list ,list))
>        (loop for elt in list by #'cddr
>              do (body elt)
>              finally (return (retval nil)))))

Uh, don't you need some FUNCALLs? This isn't c.l.s you know.

-Peter

-- 
Peter Seibel                                     ·····@gigamonkeys.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Thomas F. Burdick
Subject: Re: anamorphic macros
Date: 
Message-ID: <xcv4qdb8rdf.fsf@conquest.OCF.Berkeley.EDU>
Peter Seibel <·····@gigamonkeys.com> writes:

> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> 
> > But yuck, what's with all the gensyms?!?!  The whole point of lifting
> > the body of the code is to insulate it from the LOOP's lexical
> > environment:
> >
> >   (defmacro dolist-by-cddr ((var list &optional retform) &body body)
> >     `(let ((body (lambda (,var) ,@body))
> >            (retval (lambda (,var) ,@retform))
> >            (list ,list))
> >        (loop for elt in list by #'cddr
> >              do (body elt)
> >              finally (return (retval nil)))))
> 
> Uh, don't you need some FUNCALLs? This isn't c.l.s you know.

Ahem, yeah.  I guess the Lisp1 at work is starting to rot my brain :-P
From: ivant
Subject: Re: anamorphic macros
Date: 
Message-ID: <1115720193.484885.187610@f14g2000cwb.googlegroups.com>
Thomas F. Burdick wrote:
> Ahem, yeah.  I guess the Lisp1 at work is starting to rot my brain
:-P

Still better than the Lisp0 most of us get :-(

--
My main complain against Java is that it has too few parentheses
From: Rob Warnock
Subject: Re: anamorphic macros
Date: 
Message-ID: <NqKdnVHVgvGMfxzfRVn-1g@speakeasy.net>
Peter Seibel  <·····@gigamonkeys.com> wrote:
+---------------
| ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
| > But yuck, what's with all the gensyms?!?!  The whole point of lifting
| > the body of the code is to insulate it from the LOOP's lexical
| > environment:
| >   (defmacro dolist-by-cddr ((var list &optional retform) &body body)
| >     `(let ((body (lambda (,var) ,@body))
| >            (retval (lambda (,var) ,@retform))
| >            (list ,list))
| >        (loop for elt in list by #'cddr
| >              do (body elt)
| >              finally (return (retval nil)))))
| 
| Uh, don't you need some FUNCALLs? This isn't c.l.s you know.
+---------------

Or put the first two in an FLET instead of LET.
Then (BODY foo) & (RETVAL foo) would work.


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Thomas F. Burdick
Subject: Re: anamorphic macros
Date: 
Message-ID: <xcvvf5o7rw5.fsf@conquest.OCF.Berkeley.EDU>
····@rpw3.org (Rob Warnock) writes:

> Peter Seibel  <·····@gigamonkeys.com> wrote:
> +---------------
> | ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> | > But yuck, what's with all the gensyms?!?!  The whole point of lifting
> | > the body of the code is to insulate it from the LOOP's lexical
> | > environment:
> | >   (defmacro dolist-by-cddr ((var list &optional retform) &body body)
> | >     `(let ((body (lambda (,var) ,@body))
> | >            (retval (lambda (,var) ,@retform))
> | >            (list ,list))
> | >        (loop for elt in list by #'cddr
> | >              do (body elt)
> | >              finally (return (retval nil)))))
> | 
> | Uh, don't you need some FUNCALLs? This isn't c.l.s you know.
> +---------------
> 
> Or put the first two in an FLET instead of LET.
> Then (BODY foo) & (RETVAL foo) would work.

But then you get back to needing gensyms, because the point at which
LIST is evaluated will see BODY and RETVAL.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | Free Mumia Abu-Jamal! |
     ,--'    _,'   | Abolish the racist    |
    /       /      | death penalty!        |
   (   -.  |       `-----------------------'
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Sashank Varma
Subject: Re: anamorphic macros
Date: 
Message-ID: <1116040957.325690.201990@g44g2000cwa.googlegroups.com>
Thomas F. Burdick wrote:

>            /|_     .-----------------------.
>          ,'  .\  / | Free Mumia Abu-Jamal! |
>      ,--'    _,'   | Abolish the racist    |
>     /       /      | death penalty!        |
>    (   -.  |       `-----------------------'
>    |     ) |
>   (`-.  '--.)
>    `. )----'

Sad to see that Marxist .sig cat is no more.
From: Thomas F. Burdick
Subject: Re: anamorphic macros
Date: 
Message-ID: <xcvacmx7rdv.fsf@conquest.OCF.Berkeley.EDU>
"Sashank Varma" <············@yahoo.com> writes:

> Thomas F. Burdick wrote:
> 
> >            /|_     .-----------------------.
> >          ,'  .\  / | Free Mumia Abu-Jamal! |
> >      ,--'    _,'   | Abolish the racist    |
> >     /       /      | death penalty!        |
> >    (   -.  |       `-----------------------'
> >    |     ) |
> >   (`-.  '--.)
> >    `. )----'
> 
> Sad to see that Marxist .sig cat is no more.

If you doubt that my sab cat is still a Marxist, you should look up
the history of the early ILD.  I live in Germany now, so she's still
quite an Internationalist.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | Free Mumia Abu-Jamal! |
     ,--'    _,'   | Abolish the racist    |
    /       /      | death penalty!        |
   (   -.  |       `-----------------------'
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Frode Vatvedt Fjeld
Subject: Re: anamorphic macros
Date: 
Message-ID: <2hoebn11om.fsf@vserver.cs.uit.no>
"Steven M. Haflich" <···@alum.mit.edu> writes:

> I think Frode may be prejusiced against loop.  Acceptance of loop is
> something of a religious issue among Lisp programmers.

I'm not prejudiced against loop, I like it and use it all the time. As
"surface syntax", which was the whole point of what I wrote. I have
been bitten a couple of times by using loop in macro-expansions, and
that's why I stopped doing that. Loop-finish is one obvious problem:

  (loop for thang in foo
       do (do-my-thingies (thingy thang)
            (unless (bar thingy)
               (loop-finish))))

If do-my-thingies expands to a loop, this is not going to work well,
precisely because loop is anamorphic.

Also, the whole point of loop IMHO is to make it convenient for the
programmer to express many variations of iteration (i.e. at the
"surface level"). A macro-expansion is generated by machines
(programmed by humans, but not at "surface level"), which makes this
(otherwise great) asset of loop more or less irrelevant, and also the
regularity of "normal" lisp syntax somewhat more important.

-- 
Frode Vatvedt Fjeld
From: Zach Beane
Subject: Re: anamorphic macros
Date: 
Message-ID: <m3u0lehpv7.fsf@unnamed.xach.com>
Frode Vatvedt Fjeld <······@cs.uit.no> writes:

> loop is anamorphic.

I think you (and everyone else) mean "anaphoric".

Zach
From: Frode Vatvedt Fjeld
Subject: Re: anamorphic macros
Date: 
Message-ID: <2hk6ma25ew.fsf@vserver.cs.uit.no>
Zach Beane <····@xach.com> writes:

> I think you (and everyone else) mean "anaphoric".

Actually, I just wrote "ana" and did dabbrev-expand, but probably,
yes :)

-- 
Frode Vatvedt Fjeld
From: Christopher C. Stacy
Subject: Re: anamorphic macros
Date: 
Message-ID: <uy8apefxl.fsf@news.dtpq.com>
Zach Beane <····@xach.com> writes:

> Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> 
> > loop is anamorphic.
> 
> I think you (and everyone else) mean "anaphoric".

Since it was Lisp, I just assumed you all meant "euphoric".
From: Bulent Murtezaoglu
Subject: Re: anamorphic macros
Date: 
Message-ID: <87br7n6nne.fsf@p4.internal>
I believe the word is 'anaphoric' not 'anamorphic' 

http://www.answers.com/anaphoric

http://www.answers.com/anamorphic

Please correct me if I am wrong. 

cheers,

BM
From: Steven M. Haflich
Subject: Re: anamorphic macros
Date: 
Message-ID: <Ny9fe.2520$X21.805@newssvr21.news.prodigy.com>
Bulent Murtezaoglu wrote:

> I believe the word is 'anaphoric' not 'anamorphic' 
> 
> http://www.answers.com/anaphoric
> 
> http://www.answers.com/anamorphic

I agree, "anaphoric" has morphed to become "anamorphic" prosy.

Note that the line above scans naturally as anapest hexameter,
if it matters...
From: Steven M. Haflich
Subject: Re: anamorphic macros
Date: 
Message-ID: <gKbfe.2820$X21.354@newssvr21.news.prodigy.com>
Frode Vatvedt Fjeld wrote:

> I'm not prejudiced against loop, I like it and use it all the time. As
> "surface syntax", which was the whole point of what I wrote. I have
> been bitten a couple of times by using loop in macro-expansions, and
> that's why I stopped doing that. Loop-finish is one obvious problem:
> 
>   (loop for thang in foo
>        do (do-my-thingies (thingy thang)
>             (unless (bar thingy)
>                (loop-finish))))
> 
> If do-my-thingies expands to a loop, this is not going to work well,
> precisely because loop is anamorphic.

I agree.  I didn't consider this because I never use loop-finish.  This
just gives me another reason not to use it.

loop0finish is not very well defined.  It stands out as the only
lexical operator defined inside loop.  Try recursively macroexpanding
the following in your favorite implementation to explore the
discrepency between the ANS description and your implemenation.

(loop
     for p in (if (oddp (random 10)) (loop-finish) (list-all-packages))
     collect p)

The ANS says

  The loop-finish macro can be used lexically within an extended loop 

  form to terminate that form ``normally.'' That is, it transfers control
  to the loop epilogue of the lexically innermost extended loop form.
  This permits execution of any finally clause (for effect) and the
  return of any accumulated result.

The ANS doesn't say anything about loop-finish not being usable in
vaiable initialization forms, but I bet most implementations don't
support it.

> Also, the whole point of loop IMHO is to make it convenient for the
> programmer to express many variations of iteration (i.e. at the
> "surface level"). A macro-expansion is generated by machines
> (programmed by humans, but not at "surface level"), which makes this
> (otherwise great) asset of loop more or less irrelevant, and also the
> regularity of "normal" lisp syntax somewhat more important.

I generally agree with this.
From: Nicolas Neuss
Subject: Re: anamorphic macros
Date: 
Message-ID: <87acn7s8ii.fsf@ortler.iwr.uni-heidelberg.de>
I prefer the name WHEREAS proposed by Erik Naggum some time ago.  I have
the following code which does more things (although I admit that I almost
never use the extensions):

(defmacro whereas (clauses &rest body)
  "Own implementation of the macro @function{whereas} suggested by Erik
Naggum (c.l.l., 4.12.2002)."
  (if (null clauses)
      `(progn ,@body)
      (destructuring-bind ((var expr &optional type) . rest-clauses)
	  clauses
	`(let ((,var ,expr))
	  ,(when type `(declare (type ,type ,var)))
	  (when ,var
	    (whereas ,rest-clauses ,@body))))))
From: Jens Axel Søgaard
Subject: [OT] Re: anamorphic macros
Date: 
Message-ID: <4280dd8b$0$306$edfadb0f@dread12.news.tele.dk>
Pascal Costanza wrote:
> Knut Olav Bøhmer wrote:

>> Some people don't like anamorphic macros. I need help to understand why
>> anamorphic macros is not a good thing. As I have most of my programming
>> experience in perl, you can understand that it's difficult for me to
>> understand (If you know perl).
>>
>> Maybe there exists some situations I haven't thought about, where
>> anamorphic macros are something I should really avoid.
> 
> If an anaphoric macro creates a binding with a default name, you may get 
> conflicts when you nest two uses of that macro. Simple example:
> 
> (defmacro awhen (expr &body body)
>   `(let ((it ,expr))
>      (when it ,@body)))
> 
> (awhen (+ 1 2)
>   (awhen (* 3 4)
>     (print it)))

Using syntax-case this is written:

   > (define-syntax (awhen stx)
       (syntax-case stx ()
         ((awhen expr body ...)
          (with-syntax ([it (datum->syntax-object #'awhen 'it)])
            #'(let ((it expr))
                (when it body ...))))))

The call to datum->syntax-object takes the datum 'it and
gives it the same lexical properties as the syntax-object awhen.

> This prints 12 because IT refers to the inner binding. There is no way 
> in the inner code to refer to the outer IT anymore.

   > (awhen (+ 1 2)
            (awhen (* 3 4)
                   it))
   12

> This is especially bad when it's not obvious that there is an inner 
> binding:
> 
> (defmacro bla (&body body)
>   `(awhen (* 3 4) ,@body))
> 
> (awhen (+ 1 2)
>   (bla (print it)))
> 
> Here, IT refers to the binding of an inner AWHEN, but you wouldn't know 
> if you don't know the implementation details of the BLA macro.

Here is a difference:

   > (define-syntax (bla stx)
       (syntax-case stx ()
         ((bla body ...)
          #'(awhen (* 3 4) body ...))))

   > (awhen (+ 1 2)
            (bla (display it)))
   3

The user doesn't have to worry about how bla is implemented.


For some reason I dislike implicit identifiers, so I like
the when-let solution.

-- 
Jens Axel Søgaard
From: Pascal Costanza
Subject: Re: [OT] Re: anamorphic macros
Date: 
Message-ID: <3ec71iF2brqvU1@individual.net>
Jens Axel S�gaard wrote:
> Pascal Costanza wrote:
> 
>> Knut Olav B�hmer wrote:
> 
> 
>>> Some people don't like anamorphic macros. I need help to understand why
>>> anamorphic macros is not a good thing. As I have most of my programming
>>> experience in perl, you can understand that it's difficult for me to
>>> understand (If you know perl).
>>>
>>> Maybe there exists some situations I haven't thought about, where
>>> anamorphic macros are something I should really avoid.
>>
>>
>> If an anaphoric macro creates a binding with a default name, you may 
>> get conflicts when you nest two uses of that macro. Simple example:
>>
>> (defmacro awhen (expr &body body)
>>   `(let ((it ,expr))
>>      (when it ,@body)))
[...]

>> This is especially bad when it's not obvious that there is an inner 
>> binding:
>>
>> (defmacro bla (&body body)
>>   `(awhen (* 3 4) ,@body))
>>
>> (awhen (+ 1 2)
>>   (bla (print it)))
>>
>> Here, IT refers to the binding of an inner AWHEN, but you wouldn't 
>> know if you don't know the implementation details of the BLA macro.
> 
> 
> Here is a difference:
> 
>   > (define-syntax (bla stx)
>       (syntax-case stx ()
>         ((bla body ...)
>          #'(awhen (* 3 4) body ...))))
> 
>   > (awhen (+ 1 2)
>            (bla (display it)))
>   3
> 
> The user doesn't have to worry about how bla is implemented.

Yes, that's an advantage of sterile macros...

> For some reason I dislike implicit identifiers, so I like
> the when-let solution.

Exactly. ;)


Pascal

-- 
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
From: Jens Axel Søgaard
Subject: Re: [OT] Re: anamorphic macros
Date: 
Message-ID: <4280faa7$0$201$edfadb0f@dread12.news.tele.dk>
Pascal Costanza wrote:
> Jens Axel Søgaard wrote:
>> Pascal Costanza wrote:
>>> Knut Olav Bøhmer wrote:

> Yes, that's an advantage of sterile macros...

Well, since awhen introduces IT into the expansion, it isn't
sterile^H^H^H^H^H^H^H hygienic.

-- 
Jens Axel Søgaard