StandaloneDeriving always struck me as a really heavyweight way to write those
instances. EmptyDataDecls in many ways should have been in all along while
StandaloneDeriving is a rather peculiar ghc'ism.
I'm personally in favor of just making EmptyDataDecls work better here.
-Edward
On Aug 14,
On Mon, Aug 12, 2013 at 9:33 AM, Richard Eisenberg e...@cis.upenn.edu wrote:
My proposal below doesn't really give different behavior for EmptyDataDecls
in the two scenarios… the available constructs are the same under either H98
or H2010. It's just that the distance from the spec is
Maybe it's best if Show, Ord, etc., echo the new behavior for Eq, if
EmmptyDataDecls is specified. The reason for the check in cond_stdOK is to make
sure that we're conforming to the Haskell standard. But, if the user has
specified EmptyDataDecls, then we're not bound to that requirement
Technically, EmptyDataDecls is part of Haskell 2010, so it is standard
these days (and H2010 is our default in GHC.)
As far as I know, the 2010 standard doesn't address this point about
deriving for empty data decls, but I agree with your reasoning here.
It's more consistent to have it apply to
According to the Haskell 2010 report
(http://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18200011),
a datatype with no constructors cannot derive any instances.
But, instead of creating a new extension for this feature, what about just
co-opting EmptyDataDecls? More
On Sun, Aug 11, 2013 at 10:00 PM, Richard Eisenberg e...@cis.upenn.edu wrote:
According to the Haskell 2010 report
(http://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18200011),
a datatype with no constructors cannot derive any instances.
You're quite right! I should have
Hi all,
I just started GHC development made a commit for ticket 7401:
http://ghc.haskell.org/trac/ghc/ticket/7401
My patch is here:
https://github.com/osa1/ghc/commit/3ec257ff48372de30df59cd8854ce28954c9db95
`make test` succeeds. My test case for this patch is something like this:
data D
Hello Omer,
It is almost certainly the case that the implementation of these
functions should not be the constant return True function. Furthermore,
the implementation should probably be done using:
http://ghc.haskell.org/trac/ghc/ticket/2431
Edward
Excerpts from Ömer Sinan Ağacan's
