Implement a gradual approach to learning about shadowing

[dhess]

We've decided that variable shadowing in Primer is OK, and that what we'll do is point it out (in the UI) when it happens, along with some helpful text, a visual indication of which variable is being shadowed, etc.

However, we also think there's merit in the approach taken by Elm (or at least, was taken by Elm at some point — I'm not sure whether Elm still has these semantics), and that is to disallow shadowing outright. This would presumably be enforced at some language level (possibly beginner level, or possibly somewhat later, see below), and then relaxed at higher levels. (We would not enforce this in imported dependencies of the student's program, only in the program that they're editing.)

Additionally, we also decided previously that it might be a good idea to go one step further, and disallow any variables having the same name in a given program. The thinking is:

• Initially, say that no two variables in the same program can have the same name. Hopefully this will be a simpler way to start, and to reinforce the idea that every variable binding in the program is independent of all others by requiring them to have different names.
• Next, perhaps introduce the idea that there can be a variable named x in the student's program, and also a variable named x in an imported module, and that's OK, because they have different module scope. In fact, there would be no practical way to enforce this, since we want to share code with other people, etc.
• Finally, introduce lexical scope, and intra-program/module shadowing.

We will also need to think about how this sequence intersects with evaluation; e.g., where does recursion fit into this sequence, or even simply calling the same non-recursive function two or more times in the same program evaluation?

(This is probably a post-Primer-language 1.0 feature.)

[brprice]

• Initially, say that no two variables in the same program can have the same name. Hopefully this will be a simpler way to start, and to reinforce the idea that every variable binding in the program is independent of all others by requiring them to have different names.

I'm slightly worried about the pedagogy of enforcing this before mentioning scopes. I'm imagining a student thinking that "variables" are like "global (mutable) variables" from imperative languages, and/or trying to write non-well-scoped programs. However, I can also believe that my worry is only brought on by having too much familiarity with scoping already!

[dhess]

Sure, this was just off the cuff, and the approach would need to be trialed.