Hello,
On Fri, Apr 25, 2008 at 3:00 PM, Simon Marlow <[EMAIL PROTECTED]> wrote:
> ...
> 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
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 n
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 a
Hello,
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.
By the way, method definitions already have a distinction between what
is on
It is illegal to give a binding for a class method that is not in
scope, but thename under which it is in scope is immaterial; in
particular, it may be aqualified name.
I believe this was a change introduced in H'98 to tidy up the
language. Previously, if a class was imported quali
consider Haskell 98 report, section 4.3.2 "Instance Declarations":
The declarations d may contain bindings only for the class methods of C.
It is illegal to give a binding for a class method that is not in scope, but the
name under which it is in scope is immaterial; in particular, it
