Am 17.11.2005, 23:18 Uhr, schrieb Daishi Kato <[EMAIL PROTECTED]>:
[...]
I cannot think of an easy way to fix this without having to make the
macro quite syntax-aware, though. Therefore I would rather suggest to
implement the whole thing for regular let forms in one of the compiler's
optimization passes ;)
I first thought this was an optimization issue in the complier,
but it might be not, because in some case there is a side effect,
while assigning let variables. If it is possible for the compiler
to optimize with the normal let, I would prefer it.
Right, with sideeffects this can get quite nasty... So optimization by
default is not really possible :(
Would it be worth improving the lazy-let macro
so that it understands at least let and quote forms?
[...]
I think it is rather complicated. Maybe that's worth it -- but it depends
on what you want to use it for. If you are careful about what you are
doing,
the present version can be useful as well...
By the way, another thing that is problematic except let constructs and
quotes are lambda expressions. If I write something like
(let ((a (get-a)))
(lambda (blubb) (work-with a blubb)))
I do that because I want (get-a) to be called only once and the result
stored
in a to be part of the anonymous procedure's environment. However,
replacing
let with lazy let in the above snippet will cause it to macroexpand into
(begin
(lambda (blubb)
(work-with (get-a) blubb)))
On the other hand
(lazy-let ((a (get-a)))
a
(lambda (blubb)
(work-with a blubb)))
expands into
(let ((a (get-a)))
(begin
a
(lambda (blubb)
(work-with a blubb))))
And so we encounter the philosophical question which one is the desired
behaviour and the technical question how to make it consistent :)
cu,
Thomas
_______________________________________________
Chicken-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/chicken-users
