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 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 different.
>
> Persona
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 different.
Personally, I'm loathe to stray from a well-defined note in a standard for
On Sun, Aug 11, 2013 at 10:00 PM, Richard Eisenberg 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 looked over the t
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 concretely
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 al
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 anymore
Removing `null data_cons`(compiler/typecheck/TcDeriv.lhs 1105) check
for eq instance declarations fixes this, code generation part would be
same(changes in TcGenDeriv.hs were wrong and TcGenDeriv needs to be
unchanged)but I'm not sure how to remove that check only for eq
instance(Show, Ord, etc. so
> It is almost certainly the case that the implementation of these
> functions should not be the constant return True function.
Yeah, I just checked that and looks like GHC generates `error $ Void ==`
Derived instances
Derived instances:
in
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 messag
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
11 matches
Mail list logo
