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

Andreas Fuchs asf at boinkor.net
Tue Nov 16 16:01:28 UTC 2004


Today, Joerg-Cyril Hoehle <Joerg-Cyril.Hoehle at t-systems.com> wrote:
> Andreas Fuchs wrote:
>> I did the non-sensible thing instead and hacked together a more or
>> less macrolet/flet/labels-aware code walker that uses custom
>> lexical environments.
> Now that's cool. Congratulations!

Thanks (-:

I think I'll integrate your patches (& make a new release, perhaps
1.1pre1?) tomorrow, btw.

>> I thought it would be much harder to get this to work)
> I also wouldn't have expected this to be possible in so little code.
>
>> I'm not entirely sure that mine is the way to go. But yours (as the
>> more conservative one) sounds good, from a maintainer's point of
>> view.
> I don't know what you mean by "yours". I feel quite uncomfortable at
> using a package that may generate incorrect code without warnings.

I was referring to the suggestion of having it accept a subset of
macrolets (the ones that don't expand to iterate clauses, as the
with-hashtable-iterator and with-package-iterator ones do). Of course,
generating bad code without warning is a really bad idea.

>> A hacky solution isn't hard. One that is guaranteed to work with
>> all macrolet/flet combinations [...] will be quite a bit harder.
> I'll have to review whether your code is correct or what the
> restrictions are. I still find it hard to believe that a
> *macroexpand-hook* might suffice.

a *macroexpand-hook* alone is not sufficient; it's only there to
prevent macroexpand from expanding macros that could be defined in an
FLET of LABELS in the lexical scope. The real expansion / nonexpansion
work is done by the walker-macroexpand function. Hmm. Now that I think
about it, the macroexpand-hook might not be necessary at all. Neat!

> Please explain why you consider your code hacky (or restricted).
> Similarly, it would have helped if J.Amsterdam had laid out what
> exactly is hairy or subtle (e.g. what about multiple-values in with
> clause and other notes).

Well, there might be some edge cases where it breaks. I thought I saw
some failures with macrolet functions that contained DECLARE
forms. Perhaps that was just a tester error, though. I will report
when I find examples that go boom (-:

> I have a general feeling that it would be better to have the
> implementation do most of the expansion work, especially
> w.r.t. error reporting. The current Iterate walkers assume
> syntactically correct code and I expect implementations to be good
> at reporting syntax and other errors.

Right. That's why I'd be most interested in a solution that doesn't
require a code walker, too. Maybe, if we customized *macroexpand-hook*
enough, we could use that condition idea I talked about on cll.

>> OAO20TM
> ?!? Google finds nothing about this.

Heh, it's a pun on the abbreviation of Once And Only Once (OAOO) -
Once And Only 20 Times More (-:

> Regards,
> 	Jorg Hohle

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




More information about the iterate-devel mailing list