Truffleruby: Polyglot shell does not seem to support local variables

[fniephaus]

Tested with GraalVM CE 19.0.0 on macOS:

irb

$ irb --jvm
irb(main):001:0> x = 42
=> 42
irb(main):003:0> x
=> 42

Polyglot Shell

$ polyglot --jvm --shell
GraalVM MultiLanguage Shell 19.0.0
  Ruby version 2.6.2
ruby> x = 42
42
ruby> x
undefined local variable or method `x' for main:Object (NameError)
        at <ruby> <top (required)>(<shell>:1:0)
        at <ruby> parsing-request(Unknown)
ruby> $x = 42
42
ruby> $x
42

Expected behavior: identical

[eregon]

We were discussing this issue with the team not long ago.
I agree it should work for the polyglot shell.

However, it's unclear to me whether different Context#eval should share top-level local variables, particularly if using File sources like

Context.eval(Source.newBuilder("ruby", new File("foo.rb").build()));

Do you have other use cases for sharing local variables with Context#eval except REPLs?

[fniephaus]

@eregon thanks for the info. I'd also be interested in support for different scoping mechanisms in the polyglot API. In this case, users expect the identical behavior to irb I'd say. In terms of other use cases, I can only think of something like Jupyter Notebooks (which would still be an important use case to support I think).

[eregon]

For Jupyter Notebooks (and also e.g., Galaaz), it's always possible to use language-specific APIs like Kernel#eval(code, binding) and pass binding around as desired.

For the case of the polyglot shell, I think one way to detect if we want to share local variables would be to use Source#isInteractive(). Then other use cases like Jupyter Notebooks could set that too to be language-agnostic.

[fniephaus]

Sounds reasonable. Nonetheless, I'd be curious to know what @chumer thinks about this.

[fniephaus]

For Jupyter Notebooks (and also e.g., Galaaz), it's always possible to use language-specific APIs like Kernel#eval(code, binding) and pass binding around as desired.

In a polyglot notebook implementation, we might want to implement the notebook kernel e.g. with the embedder API or based on an existing NodeJS server. Should the notebook kernel include this language specific eval/scoping information for all languages?

[chumer]

We have discussed this internally and we came to the conclusion that is probably best that Context#eval shares top-level locals by default. We have plans to add a scoped eval capability in the Context API.

[chrisseaton]

Fix for this on the way.

[chrisseaton]

Fixed in a84b16fc92020d8344e5b47c1841b2f1f8c47f52.

[chrisseaton]

Just confirmed this work as expected in the release that's in a couple of days.