From: John Wiseman
Subject: with-*-iterator and macros vs. closures
Date: 
Message-ID: <m2it4zlt6o.fsf@server.local.lemon>
Hello.

with-hash-table-iterator and with-package-iterator are defined to
create macros using macrolet that can be used inside the body of the
with-* form to perform the iteration.  Basically I'm wondering why
it's defined to use macrolet, when there's nothing requiring the
iterator to be a macro, and it would seem there would be some (minor)
advantages if it were a closure (the iterator could be passed to
another function more easily, e.g.).

Maybe there disadvantages to using a closure, maybe the reasons are
historical.  I'm just curious what the reasons are, if there are any.


John Wiseman

From: Joe Marshall
Subject: Re: with-*-iterator and macros vs. closures
Date: 
Message-ID: <P2VK8.10877$fT5.2832433@typhoon.ne.ipsvc.net>
"John Wiseman" <·······@server.local.lemon> wrote in message ···················@server.local.lemon...
>
> Hello.
>
> with-hash-table-iterator and with-package-iterator are defined to
> create macros using macrolet that can be used inside the body of the
> with-* form to perform the iteration.  Basically I'm wondering why
> it's defined to use macrolet, when there's nothing requiring the
> iterator to be a macro, and it would seem there would be some (minor)
> advantages if it were a closure (the iterator could be passed to
> another function more easily, e.g.).
>
> Maybe there disadvantages to using a closure, maybe the reasons are
> historical.  I'm just curious what the reasons are, if there are any.

It wasn't *that* long ago that avoiding allocating storage was an
important performance technique.
From: Tim Moore
Subject: Re: with-*-iterator and macros vs. closures
Date: 
Message-ID: <adhhin$o4t$0@216.39.145.192>
On Tue, 04 Jun 2002 01:51:43 GMT, Joe Marshall <·············@attbi.com> wrote:
>
>"John Wiseman" <·······@server.local.lemon> wrote in message ···················@server.local.lemon...
>>
>> Hello.
>>
>> with-hash-table-iterator and with-package-iterator are defined to
>> create macros using macrolet that can be used inside the body of the
>> with-* form to perform the iteration.  Basically I'm wondering why
>> it's defined to use macrolet, when there's nothing requiring the
>> iterator to be a macro, and it would seem there would be some (minor)
>> advantages if it were a closure (the iterator could be passed to
>> another function more easily, e.g.).
>>
>> Maybe there disadvantages to using a closure, maybe the reasons are
>> historical.  I'm just curious what the reasons are, if there are any.
>
>It wasn't *that* long ago that avoiding allocating storage was an
>important performance technique.

with-hash-table-iterator and with-package-iterator are in the language
for only one reason: to support the hash table and package iteration
forms in the LOOP macro.  They're designed to be be compatible with
all the other weird shit that goes on inside the body of LOOP.  It
would have been too controversial to require that forms that support
"high performance" constructs like LOOP create closures.

Tim
From: Thomas F. Burdick
Subject: Re: with-*-iterator and macros vs. closures
Date: 
Message-ID: <xcvk7pex08o.fsf@flood.OCF.Berkeley.EDU>
"Joe Marshall" <·············@attbi.com> writes:

> "John Wiseman" <·······@server.local.lemon> wrote in message ···················@server.local.lemon...
> >
> > Hello.
> >
> > with-hash-table-iterator and with-package-iterator are defined to
> > create macros using macrolet that can be used inside the body of the
> > with-* form to perform the iteration.  Basically I'm wondering why
> > it's defined to use macrolet, when there's nothing requiring the
> > iterator to be a macro, and it would seem there would be some (minor)
> > advantages if it were a closure (the iterator could be passed to
> > another function more easily, e.g.).
> >
> > Maybe there disadvantages to using a closure, maybe the reasons are
> > historical.  I'm just curious what the reasons are, if there are any.
> 
> It wasn't *that* long ago that avoiding allocating storage was an
> important performance technique.

I'm guessing the argument wouldn't have been exactly that.  After all,
a good compiler, like Python, produces the same code for:

  (defun foo (x)
    (flet ((get-next ()
             (if (zerop x)
                 (values nil x)
                 (values t (decf x)))))
      (loop (multiple-value-bind (more? value) (get-next)
              (if more?
                  (do-something-with value)
                  (return))))))

and

  (defun bar (x)
    (macrolet ((get-next ()
                 `(if (zerop x)
                      (values nil x)
                      (values t (decf x)))))
      ;; ... etc ...
      ))

In this case, you only pay for the extra flexibility if you use it.

I'm guessing that not everyone was comfortable with requiring
compilers to be that smart.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'