Global scope confusion again

Tamas_Papp · January 25, 2019, 5:48pm

I think the immediate issue is unrelated (or very weakly related) to scoping — it is simply a pre-existing variable g. Eg

julia> g = 1
1

julia> g() = 1
ERROR: cannot define function g; it already has a value
Stacktrace:
 [1] top-level scope at REPL[2]:1

favba · January 25, 2019, 5:55pm

Maybe the error message could be improved… something like: "cannot define function g: "g" is already used as a variable name.

StefanKarpinski · January 25, 2019, 5:58pm

PRs welcome if someone has a better wording, although the current wording seems fairly clear already.

favba · January 25, 2019, 6:05pm

One could read the “it” in the message as “function g”. Then the error will read “function g already has a value” and one might understand from that that you cannot redefine “function g”.
I’d make a PR if I someone could point me in which file the error message is written.

Tamas_Papp · January 25, 2019, 6:07pm

I think the issue here is that the error message and the subsequent suggestions/questions on this forum were just completely ignored.

StefanKarpinski · January 25, 2019, 6:26pm

Let’s make the most of it and see if we can’t get a better error message out of the experience.

jlperla · January 25, 2019, 6:40pm

Yup. To me this is an example of noise being generated by the confusion around scoping, which leads people to miss a more obvious problem. I think the error message is otherwise clear if people stop worrying about scope issues, like they were able to before.

Paul · January 25, 2019, 7:42pm

Yes. That’s exactly right. My subjective global perception concerning Julia suddenly changed on the account of this scoping " tweak." In my mind, it is now a product by programmers for programmers. Within that revised mental model concerning the product, Stefan is correct in stating that my reaction to the scoping rule is an over-reaction.

There was a time in history when one had to be either mechanically inclined, rich and probably both to operate an automobile. My time and cognitive bandwidth are sufficiently limited that it does not make sense for me to operate Julia. Especially, because I imagine that there will probably be more unduly taxing surprises down the road.

oheil · January 25, 2019, 7:48pm

Don’t give up. It seems that there is just a simple small missunderstanding which bothers you. If you try to overcome it now you will be rewarded with the best programming environment currently available (my opinion).
I would be more specific but it is not so clear to me what exactly is the problem.

jlperla · January 25, 2019, 7:54pm

He summarized his issue elegantly. While I think that it is largely inaccurate, I have to admit that the scoping issues and the inability to solidify a solution are not a good signal. In my mind, another bad signal is that whenever anyone mentions debuggers on these forums they get attacked with “debuggers are not necessary if you write code properly… i have written 100,000 lines of code without them!” responses.

Luckily, the broader signal we have on both of these is: (1) the scoping issue will be resolved, but they want to make sure they do it right; and (2) lots of people want a Matlab-style debugger, but the funding isn’t there yet and it isn’t something the “power users” have incentives to do on their own.

So, with all of that. I also implore you not to give you, as there are other signals you may have missed.

Tamas_Papp · January 25, 2019, 8:06pm

I would say that this is a misrepresentation, especially in light of recent developments like

github.com/JuliaDebug/ASTInterpreter2.jl

Towards a semi-performant recursive interpreter

JuliaDebug:master ← timholy:teh/localmt

opened 10:25PM - 20 Jan 19 UTC

timholy

+1567 -320

This is a pretty big overhaul of this package. I've tried to keep its original f…unctionality, but perhaps a split should be the next step (see #32). The first 5 commits get the tests passing, with the exception of the ui tests which I didn't even look at (CC @staticfloat re #34, #36; @pfitzseb re #33). The rest is much more ambitious. I worked a lot on the performance, since an "easy" way to add robust breakpoints, etc, is via running your code in the interpreter. And of course there's interest in using the interpreter to circumvent compile-time cost. But then performance matters. The most important changes here are focused on reducing the cost of dynamic dispatch (or its equivalent here, "dynamic lowered code lookup"). Some highlights: - At the lowest level, all calls are to Builtins and IntrinsicFunctions. I used the `tfunc` data in `Core.Inference` to auto-generate an evaluator that resolve all calls with fixed number of arguments. A straightforward extension would be resolve all calls with bounded numbers of arguments (e.g., those that have between 2 and 4 arguments). - To reduce the overhead of `which`, this adds "local method tables," one per :call Expr. These are cached by exact type, since `isa(x, Int)` is fast but `isa(x, Integer)` is slow. So it uses `MethodInstance` comparisons rather than `Method` signature comparisons, even though it might look up the same lowered code. I think a slightly more elegant way to do this would be to add a new type, ```julia struct LocalMethodTable call_expr::Expr knownmethods::TypeMapEntry end ``` to the list of valid types in a `CodeInfo`. (I did it this way at first but it breaks things like basic-block computation and ssa-usage analysis. So I resorted to storing this info in a separate fields.) For a simple summation test, I'm getting about 15us per iteration. Compiled code is about 5ns, so this is still dirt-slow. But just getting it to this point was quite a major overhaul. CC @JeffBezanson, @vtjnash, @StefanKarpinski.

Also, while I recognize that you want a debugger, I don’t think that turning this thread into yet another debugger discussion is a good idea.

Tamas_Papp · January 25, 2019, 8:24pm

I think it is

github.com

JuliaLang/julia/blob/341587592daccd144f5653c86cc1e362fe209838/src/method.c#L646


      
              m->min_world = ++jl_world_counter;
              m->max_world = ~(size_t)0;
              return m;
          }
          
          // method definition ----------------------------------------------------------
          
          void print_func_loc(JL_STREAM *s, jl_method_t *m);
          
          // empty generic function def
          JL_DLLEXPORT jl_value_t *jl_generic_function_def(jl_sym_t *name,
                                                           jl_module_t *module,
                                                           jl_value_t **bp, jl_value_t *bp_owner,
                                                           jl_binding_t *bnd)
          {
              jl_value_t *gf = NULL;
          
              assert(name && bp);
              if (bnd && bnd->value != NULL && !bnd->constp)
                  jl_errorf("cannot define function %s; it already has a value", jl_symbol_name(bnd->name));
              if (*bp != NULL) {

favba · January 25, 2019, 8:26pm

In my opinion, not thinking about scoping rules lead tons of beginners to test julia interactively, use global variables inside loops, and come to the conclusion that julia is slow.
I’m of the opinion that the new behaviour is better and lead to better habits.

It can be mildly (and I mean really really mildly) annoying for interactive usage.
I also think that SoftScopeRule.jl is already the solution to this problem. The only thing missing is a REPL mode that uses it, for those who want to teach or can’t bare writing global in some places.

I think most of the users are fine with the change. It’s just that those who don’t like this change are very noisy.

Paul · January 25, 2019, 8:28pm

Thank you for your encouragement. I’ve been rooting for Julia to succeed for so many years. I’ll give it another try once I get my hands on a good Julia programming book based on Julia 1.x. Gotta give Mathematica a try, but that’s another story.

PetrKryslUCSD · January 25, 2019, 10:35pm

I am sure that with a distance of a few days this will seem just a minor issue. I wouldn’t give up on Julia if I were you: it is a very clean and understandable programming language. There will be fewer and fewer surprises as you go.

Paul · January 26, 2019, 2:41am

Thanks Petr. I really appreciate your encouragement!

Cheers

Liso · January 26, 2019, 7:41am

If this is what is intended, wouldn’t be more simple and clean to deprecate for in global scope?

Tamas_Papp · January 26, 2019, 8:54am

Not sure if you are being serious, but for is used extensively in global scope, eg for definitions that follow a template. The confusion is not about for per se.

carstenbauer · January 26, 2019, 9:35am

I think he’s not actually suggesting to deprecate for in global scope but instead pointing out (and I agree on this) that the point made by @favba isn’t a good one as it seems to suggest (maybe unintentionally) that we should make it as hard as possible for users to use Julia interactively as they will never get the speed they would get in local scopes and thus wrongly conclude that Julia is slow.

In my opinion, having an intuitive (somewhat slower) interactive mode is just as important as being able to get C-like speed in well-written functions. One thing (among many others) that made me fall in love with Julia was that I can work on any mental level (e.g. interactive exploration, somewhat performant coding, beast mode!), always choosing the one which is most appropriate for my task. We should try to avoid improving one level at the cost of another (which is a difficult task, of course).

lobingera · January 26, 2019, 12:42pm

Just a quick question, how many julia users complained, that loops didn’t create a new scope in other languages? What problems, for me as a programmer, are solved by creating a new scope at loops?

While i clearly understand scope boundaries at functions/calls or let blocks, i (for myself) still wonder, what loops have to do with scope. A loop is a repetition - the numbers known at the point of entering the loop, or just checking a condition and branch back to a previous point in the sequence of execution - but although we all tend to indent the loop content in code, was for me in most of my programming experience still the same scope; usually the scope of ‘this’ function.