[iterate-devel] Re: Macroexpansion, bindings and information flow (Iterate package)

[Andreas Fuchs]

Today, Joerg-Cyril Hoehle <Joerg-Cyril.Hoehle at t-systems.com> wrote:
> Andreas Fuchs wrote:
>>> I believe in its over 10 years of existence, it's never been able
>>> to correctly handle this form: (macrolet ((over(x) `(collect ,x)))
>>> (iterate
>>> 	(for n in '(1 2 3))
>>> 	(flet ((over(x)(declare (ignore x)) (collect 2)))
>>> 	  (over n)))) ; would yield (2 2 2) if correct
>> Actually, the current version of iterate can handle that clause
>> pretty well
>
> Did you try it out?

Argh. You're right. Serves me right for using a non-monospaced font. I
didn't see the FLET form all three times I stared at it; and I didn't
even try it out. Shame.

>> (since iterate--main--1.0--patch-6, since when we pass the *env*
>> argument to macroexpand calls). 
> I don't have GnuArch so I don't don't what this version refers to,
> but my copy of iterate-1.0.9 has *env*, &environment and
> two-argument calls to macroexpand.
>
> I claim that it does not handle it because Iterate will apply the
> MACROLET expander to the code, because it ignores the shadowing
> function definition.  The problem is independent on
> macrolet. defmacro would yield the same behaviour.
> 
> Does your copy of Iterate really return (2 2 2) ?!?

No, it doesn't. It returns (1 2 3) as you reported. Sorry for the
confusion.

>> It seems like most implementations offer code walker support
>> similar to ClTl2's. While not ANSI CL, these might be your best
>> bet.
>
> What are your thoughts w.r.t. a release of Iterate which is not
> portable, but customized to a restricted set of implementations
> (that we could put our hands on -- I only have CLISP and Corman Lisp
> here ...)? -- supposing that all interesting implementations export
> their code walkers in a useable way.

If all else fails (and I understand many people have tried), I'm not
opposed to it at all. But I don't think that iterate itself should do
that; I think a library to provide universal code-walker support (like
UFFI does for foreign function interfaces) would be better. FWIW,
cmucl and sbcl should be able to provide code-walker support (sbcl
even has an sb-cltl2 contrib specifically for that purpose).

I'm currently looking into the *MACROEXPAND-HOOK* idea. It might be a
way to a portable solution (-:

Thanks,
-- 
Andreas Fuchs, <asf at boinkor.net>, asf at jabber.at, antifuchs