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, 2013, at 1:16 AM, Austin Seipp <[email protected]> wrote: > On Mon, Aug 12, 2013 at 9:33 AM, Richard Eisenberg <[email protected]> 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 <[email protected]> >>> 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 > > > > -- > Regards, > Austin - PGP: 4096R/0x91384671 > > _______________________________________________ > Glasgow-haskell-users mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
