MessageAsTempNode>>scope question

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 ?

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?

3) is this the same issue as
http://www.nabble.com/-GRR--OutOfScopeNotification-catching-caught-me-t1414869.html
(discussed here a few months ago) ?

4) should we do something about it ?


thanks,

Stef

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 :
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
>
>
>
>

nicolas cellier wrote:
> Hi Stephane,
>
> It seems that you reposted this technical issue several times, sorry not
> to have answered sooner.

well, thanks for answering :)


> I will try my best to answer you, but best thing would be to contact
> NewCompiler team.
[...]
>> 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.

ok whenever I have enough time to do this seriously I will add to the
3448 bug report and contact the NewCompiler people.


cheers,

Stef