RFC: qualified vs unqualified names in defining instance methods

[Simon Marlow]

Claus Reinke wrote:

> i originally filed this as a bug, until Simon PJ kindly pointed
> me to the Haskell 98 report, which forces GHC to behave
> this way.. i guess i'll remember this oddity for a while, so
> i can live with it, but if it is irksome that the report allows
> me to refer to a name that is not in scope, it is far from obvious why 
> it needs to prevent me from referring to a
> name that *is* in scope (Malcolm mentioned parsing
> ambiguities as the reason for this, but in my case, GHC
> recognizes the qualified name and *complains* about it).

Is it too hard to remember that in an instance declaration you can give 
bindings for methods of the class being instantiated only?  To me, the 
oddity is that the method name must be in scope at all - this is a 
definition, not a reference, with a fixed set of things that can be defined.

However, there is a consistency issue with record construction.  The 
fields of a record construction are very much like the methods in an 
instance declaration: they are bindings for already-defined identifiers, 
and the set of available identifiers is known statically.  In Haskell 98:

aexp 	->  qcon { fbind1 , ... , fbindn }
fbind 	->  qvar = exp

so record fields can be referred to by qualified names, and in fact you 
are required to use the name by which the field is in scope - but GHC's 
DisambiguateRecordFields extension relaxes this so you're allowed to use 
the unqualified name.

So, in summary:

  - Haskell 98 is completely inconsistent here.

  - GHC + DisambiguateRecordFields is a bit more consistent
    in that unqualified names are allowed in both settings, but
    still allows qualified names in one setting but not the other.

So whatever we do we should be consistent.

It would be slightly strange if record construction required the 
unqualified name, but record update required the qualified name, when 
the field name is only in scope qualified.  So that indicates that we 
should allow either form in record construction (and instance 
declaration), i.e. Claus's suggestion + DisambiguateRecordFields.

Cheers,
	Simon