This is only tangentially related, but I would like to point out another
consideration:
Retroactively changing the meaning of extensions is _very_ annoying for
library writers. cabal makes it easy to demand particular extensions
(and make the build fail very early with a meaningful error message when
the extension isn't available), but doesn't really provide a good way
for a library to say "I want EmptyDataDecls, but if it's GHC, I also
demand that it be GHC 7.8 or later because that's when the meaning of
EmptyDataDecls changed".
~d
On 2013-08-14 01:16, Austin Seipp wrote:
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 different.
Personally, I'm loathe to stray from a well-defined note in a standard
for this.
You're right, sorry about that. I suppose we can let someone else
weigh in on this note.
I see my proposal below as a feasible solution to #7401, but I would
actually favor not implementing any change here, because the
workaround -- using standalone deriving -- is so easy and doesn't seem
to have any real drawbacks (e.g. performance).
Hmmm, I'm sort of ambivalent at this point.
Looking at the user manual[1], the relevant point for
-XStandaloneDeriving is that "Unlike a deriving declaration attached
to a data declaration, GHC does not restrict the form of the data
type..."
At the same time, from a user POV, I'd think it's reasonably annoying
to reject:
data Foo deriving (Eq, Show, Ord)
in favor of:
data Foo
deriving instance Eq
deriving instance Show
deriving instance Ord
with an extra extension - and if you happen to mention a type
variable, then it gets even longer since the context isn't inferred.
Also, given that EmptyDataDecls in its current form is now standard in
H2010, but StandaloneDeriving is not, this makes for longer code for
people who do want to be standards compliant to write the trivial
instance. And as a user of H2010, I'd see an empty data type as "a
data type" - and not an extension. So I might expect deriving to work
consistently with it, like with any other H2010 data type.
This, I suppose, is what I was alluding to when I talked about
'inconsistency' earlier. Although, then it is a question of the
standard itself! And then maybe it should be under an extra flag.
I think there are legitimate points on all sides here. But, I think
this is pretty squarely a 'user interface problem'. It's easy for us
no matter what. So, I have CC'd glasgow-haskell-users - I think
there's room for voices on this note, and I'd really appreciate users
and developers weighing in.
[1]
http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/deriving.html
Richard
On Aug 12, 2013, at 12:55 AM, Austin Seipp wrote:
On Sun, Aug 11, 2013 at 10:00 PM, Richard Eisenberg
<e...@cis.upenn.edu> wrote:
But, instead of creating a new extension for this feature, what
about just co-opting EmptyDataDecls? More concretely, I propose
this:
Under H98: EmptyDataDecls allows both the declaration of empty data
decls and deriving instances for them.
Under H2010: EmptyDataDecls allows deriving instances for empty data
decls.
This proposal brings the annoyance that H2010 no longer implies
EmptyDataDecls.
Thoughts?
Richard
IMHO, I'd find this inconsistency in extension behavior much more
annoying than just going against the standard on this note. But
that's
just my 0.02c.
--
Regards,
Austin - PGP: 4096R/0x91384671
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users