Hi Stephane,

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 
NewCompiler team.

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 
(OutOfScopeNotification).
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 
SyntaxError window.


> 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 
http://bugs.squeak.org/view.php?id=3448
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
> http://www.nabble.com/-GRR--OutOfScopeNotification-catching-caught-me-t1414869.html 
> 
>

This is absolutely related to, (also reported in 
http://bugs.squeak.org/view.php?id=3448 )

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
  [
          Transcript show:
          (Compiler new evaluate: 'a class' in: thisContext to: nil)
  ] value.

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.

Nicolas
> 
> thanks,
> 
> Stef
> 
> 
> 
>