Soft scope vs hard scope

[banx]

Consider the following code block

begin
	h = 0
	s = 2
	for i in 1:10
		y(t) = t^s+i  # comment this line to check the inconsistency.
		h += 1
	end
	h
end

Upon execution, the interpreter spits the following error: UndefVarError: h not defined
Regardless of what is the function, the error persists (e.g. defining y(t) = 0 will results with the same error). Using the short form or with function keyword gives the same error.
Of course, the expected execution in this example should give a result h = 10.

This issue was first raised in julia repo, but we've noticed that the REPL results are consistent. However, in Pluto, the error is present when the function definition is present, but no errors when the function definition is absent.

[fonsp]

Thanks!

For anyone who wants to contribute: This is caused by the different scoping rules (soft vs normal) that Julia uses for toplevel code vs inside functions. I don't know exactly how this works, but we should match the REPL behavior.

Pluto wraps code in functions (#720) if the code is 'simple'. Defining a function is one of the triggers to disable function wrapping, explaining the difference. (Just like macro calls, writing @__FILE__ instead of the function definition should give the same result.)

[banx]

I can't think of a way to fix this without keeping the same results as the REPL. I understand that wrapping code inside a function will benefit some speedup, but at the cost of inconsistencies. IMHO, I think keeping the code unwrapped will match the REPL results, as well as the performance of the REPL.

[fonsp]

I disagree with your suggestion.

For anyone who wants to contribute, don't be discouraged, and take a look at: https://github.com/stevengj/SoftGlobalScope.jl

[banx]

Thanks for pointing out to this package, I wasn't aware of its existence. I'll try to see how it can be used to resolve the issue in this context.

[hofmannmartin]

From a slack discussion that took place yesterday I can contribute the following example, where a simple comment seems to switch the behavior of a cell from non-interactive to interactive context as shown in this notebook.

I would expect consistent behavior. @fonsp Which one is the indented one?

[fonsp]

I think the switch happens because the line Ntriangles1 += 1 references a global that is not (yet) defined, which will error. I believe that this error means that #720 is not applied to the first cell, which can change the behaviour.

Can you find an example of a cell that should work, but it gives an error/warning? You could define a struct inside the cell to disable #720 .