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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
