#246: Wrong pat-match order for records
----------------------+-----------------------------------------------------
Reporter: simonpj | Owner: simonpj
Type: bug | Status: assigned
Priority: low | Milestone: _|_
Component: Compiler | Version: 6.4.1
Severity: minor | Resolution: None
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
----------------------+-----------------------------------------------------
Old description:
> {{{
> in section 3.17.2 case #6 of the haskell report
>
> There is some confusing language in the report.
> Furthermore there is
> either a bug in ghc, or hugs, depending on which way
> you interpret it.
>
> it says:
>
> # Matching against a constructor using labeled fields is
> the same as
> # matching ordinary constructor patterns except that
> the fields are
> # matched in the order they are named in the field list.
> All fields
> # listed must be declared by the constructor; fields may
> not be named
> # more than once. Fields not named by the pattern are
> ignored (matched
> # against _).
>
> If you interpret 'field list' to mean the order the fields
> appear in the
> pattern then given the code below "bar" should be
> printed, as the 'b'
> field is compared and fails so the a field is never
> matched against.
>
> If you interpret 'field list' to mean the order the fields
> were DECLARED
> in, then this should equal _|_ as the 'a' field is matched
> first and is
> undefined.
>
> ghc seems to follow the second interpretation, hugs the
> first.
>
> If the first is indeed the correct interpretation, (it is
> what I
> thought) I don't see a trivial translation to dispose of
> fields, as
> there is no easy way in Haskell98 to change the order of
> pattern matching
> without rewriting everything as a big mess of nested
> cases. (i mean,
> obviously it can be done, but the translation is harder
> than just
> placing the patterns in the right slots and dropping the
> field names)
>
> -- the code --
> data Foo = Foo { a,b::Int }
>
> au = Foo { a = undefined, b = 0 }
>
> main = case au of
> Foo { b = 1, a = 0 } -> print "foo"
> _ -> print "bar"
>
> ghc => error: Prelue.undefined
> hugs => "bar"
>
> }}}
New description:
In section 3.17.2 case 6 of the haskell report
There is some confusing language in the report.
Furthermore there is
either a bug in ghc, or hugs, depending on which way
you interpret it.
it says:
''Matching against a constructor using labeled fields is
the same as
matching ordinary constructor patterns except that
the fields are
matched in the order they are named in the field list.
All fields
listed must be declared by the constructor; fields may
not be named
more than once. Fields not named by the pattern are
ignored (matched
against _)''.
If you interpret 'field list' to mean the order the fields
appear in the
pattern then given the code below "bar" should be
printed, as the 'b'
field is compared and fails so the a field is never
matched against.
If you interpret 'field list' to mean the order the fields
were DECLARED
in, then this should equal _|_ as the 'a' field is matched
first and is
undefined.
ghc seems to follow the second interpretation, hugs the
first.
If the first is indeed the correct interpretation, (it is
what I
thought) I don't see a trivial translation to dispose of
fields, as
there is no easy way in Haskell98 to change the order of
pattern matching
without rewriting everything as a big mess of nested
cases. (i mean,
obviously it can be done, but the translation is harder
than just
placing the patterns in the right slots and dropping the
field names)
{{{
-- the code --
data Foo = Foo { a,b::Int }
au = Foo { a = undefined, b = 0 }
main = case au of
Foo { b = 1, a = 0 } -> print "foo"
_ -> print "bar"
ghc => error: Prelue.undefined
hugs => "bar"
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/246#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
