ncellier at ifrance.com
Wed Apr 11 22:48:24 UTC 2007
It seems that you reposted this technical issue several times, sorry not
to have answered sooner.
I will try my best to answer you, but best thing would be to contact
Stéphane Rollandin a écrit :
> hello list,
> if we do the following in a workspace:
> [| a |
> a := 1.
> Compiler new evaluate: '1+a' in: thisContext to: nil
> ] value
> .. it returns 2
> now if we open a Transcript and do this:
> [| a |
> a := 1.
> Transcript show:
> (Compiler new evaluate: '1+a' in: thisContext to: nil)
> ] fork
> .. we get an 'out of scope' notification
> this is very surprising to me, so I tried my best to understand what is
> happening and now I wonder:
> 1) is it an undesirable limitation of the Parser, or am I missing
> something ?
I would say this is a limitation of the Compiler.
The Compiler does not handle this case but generates an exception
The trickery that makes things work is the exception handler installed
in ParagraphEditor. As long as you evaluate your code from a
ParagraphEditor, it works. When you evaluate your code from a menu, like
put it in a file and fileIn (use 'fileIn entire file' menu item) from
a file browser, or put it in a SUnit TestCase and run it from within the
TestRunner, it does not work.
But Transcript and Workspace are both using ParagraphEditor and should
work... The difference you are exposing here is fork. When you fork the
block, it is no more protected by ParagraphEditor exception handling,
and OutOfScopeNotification signal will then answer false, leading to a
> 2) if we change MessageAsTempNode>>scope so that it returns 0 or 1, the
> second example works fine. what would be the other (undesirable) effects
> for such a change?
This is the patch i first suggested in
With this implementation, you will prevent OutOfScopeNotification to
occur for thisContext variables.
Is there an example of code where such outOfScope makes sense? The only
example i could imagine is accessing a temp var declared local to a
block outside that block.
like '[| a | a := 1] value. Transcript show: (a+1) printString'
Is there another example? NewCompiler team should help.
Once you know all implications, you should write test cases with some
examples supposed to work and some examples supposed to not work, and
check the results.
My personnal interpretation is that 'a' is not out of scope since it is
in thisContext of execution. thisContext should be the innermost scope
but one (temporaries are inner).
And indeed, a will be put in the scopeTable instVar of the encoder...
Maybe this is an implementation trick that does unify auto-declaration
of variables when they are not in the context (like done in Workspace),
see #bindingOf: and its senders.
> 3) is this the same issue as
This is absolutely related to, (also reported in
The difference is that i wanted the code to fail in my case, instead of
that, it did succeed.
Try this one, it should work in a Workspace
(Compiler new evaluate: 'a class' in: thisContext to: nil)
Also note that with the second patch i did propose according to Andreas
suggestion, your examples won't works, neither with value nor fork.
To me, this is one more evidence that handling thisContext scope should
be Compiler works, not something depending on ParagraphEditor.
> 4) should we do something about it ?
Without a doubt, yes.
When I think of it, setting scope to 0 is the best solution i see.
And cleaning the PragraphEditor error handling is required!
Maybe you should complete 3448 bug report with your own test cases.
More information about the Squeak-dev