Scope of imported names

[Simon Peyton-Jones]

Karl-Filip wrote (on 22 Oct):

| What I'm driving at is this: I propose that top level=20
| bindings shadow imported names and that qualified names can=20
| not be used to refer to declarations in the same module.=20

[His message had a lot more in it, of course, but this is the nub.]
There followed a short exchange with Wolfgang Lux, then quiet.

I've thought about this, and it's not a change that I would
be prepared to make now.  By a long way.  This stuff about
ambiguity, qualified names, and so on has been hammered out
at great length, and now is not the time to start again.

Karl-Filip made another point:

| Section 5.5.2 relates to name clashes and has an interesting=20
| example towards the end:
|=20
|   module F where
|=20
|     sin :: Float -> Float
|     sin x =3D (x::Float)
|=20
|     f x =3D Prelude.sin (F.sin x)
|=20
| where the type signature refers to the local "sin" rather=20
| than the imported although none of them is visible=20
| unqualified. These rules are quite tricky to understand, I=20
| think. They are also different in spirit from the rules for=20
| instance declarations in section 4.3.2 where the binding=20
| occurrences for the names of the methods must be qualified if=20
| the unqualified method name is not in scope. In the "sin" example
| it is allowed to resolve the=20
| name clash using the "extra" knowledge that it is illegal to=20
| provide type signatures for imported names, wheras in the=20
| case for instance declarations we may not use the=20
| corresponding "extra" knowledge that only methods in=20
| the instance'd class may be bound by the bindings.

I must say that I do agree with this.  It's a significant complication
in the syntax of the language to permit qualified names in=20
a binding position, in instance declarations only.  For example,
it leads to the productions for "funlhs" and "qfunlhs" which are
identical except that one has "var" where the other has "qvar".
These aren't small productions either; they have 6 clauses.

And, as Karl-Filip says, it's inconsistent with the type signature
stuff.

I will therefore propose the following simplification:

	remove the stuff from 4.3.2 about having a qualified name
	for the class method; after all, an instance declaration is
	only *allowed* to have declarations for the class methods

That would simplify the syntax, and make the language more consistent.
Any objections?

Simon