Hi,
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!
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.
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.
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).
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.
OAO20TM
?!? Google finds nothing about this.
Regards, Jorg Hohle
Today, Joerg-Cyril Hoehle Joerg-Cyril.Hoehle@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,