shouldn't this re-binding be an error?

[shriram]

If I write

S = 2
S = 3

I get a name binding conflict error.

However, if I write

import sets as S
S = 2

there is no error, and S is bound to 2. Indeed, in this program

import sets as S
S = 2
S = 3

only the two S = lines produce an error.

I feel like once S is bound by import, re-binding it should produce an error?

(I was tripped up by it because a student asked a question about import and I initially wrote "Pyret will make sure that S is not bound to anything else, and S.foo will …", and then checked and found that that's not actually true. It seems like a thing we would want to be able to say?)

[jpolitz]

Typically we haven't reported binding errors for shadowing across namespaces. Pyret has three – values, types, and modules (and arguably datatypes but that's basically just types).

So you can bind all of:

import lists as L
type L = List
L = list

It actually used to be the case that the as L was in the values namespace; after the module system updates module names got their own namespace (which is good for all kinds of other reasons). So I think (without firing up an old version to test) that this would have been an error ~3 years ago. Since the beginning, the type and value bindings could co-exist; we just don't notice it much because values are typically lowercase and types uppercase so convention separates them.

[jpolitz]

@blerner do we want to spec this as an error? I could go either way. It's not technically backwards compatible with code written since module system updates.... but also I can't see it biting many people, and I could see the argument that modules regressed this behavior.

[blerner]

I'm torn. I don't see any internally consistent middle ground between having three namespaces or having only one: if module imports ought to conflict with both type and value definitions... then shouldn't types and values collide?

I'm fine keeping it as three separate namespaces, it seems more internally consistent to me.