Namespacing and Shadowing

[peblair]

Currently (on master, anyway), the following program compiles:

data Foo:
  | bar(x)
end

Foo = bar(1)

Then, in the REPL, the following is possible:

> Foo
bar(1)
> a :: Foo = bar(2)
> a
bar(2)

In other words, Foo is now bound in the value and module namespaces at the same time. Shouldn't this be a shadowing error? In terms of pedagogy, it seems like we wouldn't want to explain that "this name means two disjoint things at the same time." My inclination is to update resolve-scope to maintain a separate 'unified' namespace to handle shadowing errors. Does this seem reasonable?

See Also:

• data Foo should not provide Foo as a function #571 (removal of Foo as a function defined by data:)
• Fix Module-Providing Semantics #1009 (similar namespacing issue, with modules)

[jpolitz]

I approve the idea of a unified namespace with shadowing errors across names, types, and modules.

I will note that we currently don't have syntax for shadowing a type, so this is potentially more annoying than our current shadowing rules, which are easier to circumvent when you want to.

[jpolitz]

@shriram / @blerner I'd like an opinion on if we're all on board with this change. I think it's an improvement, but it is (a) backwards incompatible and (b) does lead to a “complex things are impossible rather than hard” situation where if the value namespace takes a type name, there's no way at all to define a type with that name.

There's actually a nice module/namespacing branch that is minorly blocked on a decision here, so it would be good to have consensus.

I remembered this because of the discussion on #1221 today.

[blerner]

In broad, I think I agree with having a unified namespace. (Ironically, on the Racket mailing list right now, there's a discussion about the ability of having separated namespaces, to support individual and disjoint value and type bindings...) I'm concerned about the implementation, about fixing up name-resolution, and I'm concerned about shadowing. We'll now have four cases to consider:

• Existing value binding, shadowed value binding ==> allowed
• Existing value binding, shadowed type binding ==> currently syntactically impossible
• Existing type binding, shadowed value binding ==> ????
• Existing type binding, shadowed type binding ==> currently syntactically impossible

We should figure out what we actually want the behavior of all four of these cases to be, before we decide whether this is a uniformly good idea or not. My hunch is we want to allow type/type shadowing, but prohibit value/type or type/value shadowing on semantic rather than syntactic grounds, but I'm not sure...

[shriram]

What impact does this have on purely static operations like type-checking?

[jpolitz]

What impact does this have on purely static operations like type-checking?

I think very little in terms of the type-checker's concerns. The type checker uses whatever names are calculated by the scope step, which also resolves imports to local names. Duplicates, which is the only case where this matters, are handled the same independent of type-checking.

The only impact that slices into the type world is the fact that it adds a new way to grab space in the type namespace that can't be redefined as types.