Open shriram opened 1 year ago
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.
@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.
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.
If I write
I get a name binding conflict error.
However, if I write
there is no error, and
S
is bound to 2. Indeed, in this programonly the two
S =
lines produce an error.I feel like once
S
is bound byimport
, 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 thatS
is not bound to anything else, andS.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?)