RFC: qualified vs unqualified names in defining instance methods

[Claus Reinke]

> I think that the H98 change was a good one.  Qualified names should
> only be used in _uses_ of variables (to disambiguate) and not in
> definitions because (hopefully) there is nothing to disambiguate in a
> definition.

i was not suggesting to disallow the unqualified def
(even though it irks me as an unneccesary exception).
only that i be allowed to use a qualified name to make
the code less confusing to read (not to mention that the
qualified name is in scope, the unqualified name isn't..). 
 
> By the way, method definitions already have a distinction between what
> is on the LHS and what is on the RHS. For example, consider the
> following instance:
> 
> instance Show a => Show (Maybe a) where
>   show Nothing = "Nothing"
>   show (Just a)   = "Just " ++ show a
> 
> Here "show" is not a recursive function because the "show" on the RHS
> is different from the "show" on the LHS.

actually, both 'show's refer to the same thing here, method 'show' in 
class 'Show', and the disambiguation is via the types. now compare 
this with an instance from the class alias encoding i posted in the
other thread:

    instance (FooBar a how, How (CFoo a) (Derived (CFooBar a))) 
          => Foo a (Derived (CFooBar a)) where 
      foo = foo

is it obvious to you which foo refers to what? and though it
looks similar to your example, the disambiguation is not via
types (alone), but via what is in scope, plus the exception that 
i can/have to refer to something that isn't in scope on the left 
hand side.

for reference (spoiler ahead;-), in this example:

- 'Foo' is in scope as both 'FooAndBar.Foo' and 'Foo'
- the lhs 'foo' is not in scope, but refers to 'FooAndBar.foo',
    which is in scope
- the rhs 'foo' is in scope as both 'FooBar.foo' and 'foo',
    and comes from 'FooBar a how', not from any 'Foo'

in the same module, we have:

    class How (CFooBar a) how => FooBar a how where
      foo :: a -> Bool
      foo _ = True
      bar :: Int -> a -> [a]

here, the lhs 'foo' refers to 'FooBar.foo', which is also in
scope as 'foo', and belongs to class 'FooBar'! so the left
hand side 'foo's in the definitions refer to different things.

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).

claus