Scope problems in the macro implementation?
8 views
Skip to first unread message
Tom Lee
Aug 8, 2011, 8:19:10 AM8/8/11
to mi...@googlegroups.com
I'm trying to fix TestJVMCompiler#test_loop, which is failing
because compiled macros are automatically wrapped in an "isolated"
ScopedBody i.e. ScopedBody#parent is always nil on a macro
ScopedBody (refer to add_compiled_macro in
lib/jvm/types/intrinsics.rb).
As a result, the compiled loop macro has no visibility of the variable `a` declared outside of the macro (in the MethodDeclaration scope) and so the type of `a` cannot be inferred within the loop macro. And even if it could, it would not be valid (what's the result of adding a value to a variable that doesn't exist within a scope?).
I tried "fixing" this by adding something like this to add_compiled_macro fixes test_loop:
What *does* concern me is that it breaks test_macro_hygene, because the breakage here raises some questions about the semantics of macros. If I'm understanding the code correctly, the "isolated" ScopedBody has been added to prevent namespace conflicts at the points in the source where the macro is compiled -- we don't actually *want* a "true" ScopedBody here (even add_compiled_macro says so!), it's just a convenience to prevent macros borking things in strange and wonderful ways.
Any thoughts on how we might address this properly? At a glance, rewriting variable names in macros might suffice (e.g. `x` in a macro might be written to `x$1` or something to that effect at macro compile time) but I'm not sure that this is a particularly graceful way to do things.
Cheers,
Tom
As a result, the compiled loop macro has no visibility of the variable `a` declared outside of the macro (in the MethodDeclaration scope) and so the type of `a` cannot be inferred within the loop macro. And even if it could, it would not be valid (what's the result of adding a value to a variable that doesn't exist within a scope?).
I tried "fixing" this by adding something like this to add_compiled_macro fixes test_loop:
body.static_scope.parent = call.scope.static_scopeIt breaks a couple of the Java source tests. I have a feeling these may be either bugs in the Java source backend, or perhaps I just need to give it a bit more attention.
What *does* concern me is that it breaks test_macro_hygene, because the breakage here raises some questions about the semantics of macros. If I'm understanding the code correctly, the "isolated" ScopedBody has been added to prevent namespace conflicts at the points in the source where the macro is compiled -- we don't actually *want* a "true" ScopedBody here (even add_compiled_macro says so!), it's just a convenience to prevent macros borking things in strange and wonderful ways.
Any thoughts on how we might address this properly? At a glance, rewriting variable names in macros might suffice (e.g. `x` in a macro might be written to `x$1` or something to that effect at macro compile time) but I'm not sure that this is a particularly graceful way to do things.
Cheers,
Tom
--
Tom Lee
Software Developer / Consultant
http://tomlee.co | @tglee | 0450 112 893
(or check out my code on github)
Charles Oliver Nutter
Aug 8, 2011, 2:48:02 PM8/8/11
to mi...@googlegroups.com
It seems like a reasonable change to rewrite the variables...unless
the names of the macro variables are important in themselves. I must
admit the macro subsystem is still a little confusing to me in places,
but I'll try to have a look into this some time this week too.
- Charlie
Nick Howard
Aug 21, 2011, 6:07:17 PM8/21/11
to mi...@googlegroups.com
What do you think about rewriting the macro's variables before expanding the unquotes? Then we could evaluate the macro's body in the outer scope w/o trouble I think.
That way we can refer to outer scope variables by unquoting them, but won't have to worry about overwriting values of outer scope variables where we didn't intend to.
Reply all
Reply to author
Forward
0 new messages