Consider this module for a blog entry that I will want to put in various generic collections that require Ord {-# OPTIONS -fglasgow-exts #-} module Blog.Types where import Data.Typeable import Data.Generics data BlogEntry = Entry EpochSeconds Name Email Title Body deriving (Eq,Ord,Read,Show,Typeable) newtype Name = Name String deriving (Eq,Ord,Read,Show,Typeable) newtype Title = Title String deriving (Eq,Ord,Read,Show,Typeable) newtype Body = Body String deriving (Eq,Ord,Read,Show,Typeable) It seems really unnecessarily verbose. Having to add the OPTION header AND import Data.Typeable and Data.Generics just to derive Typeable is a beat-down. It is even more of a beat-down to have to add a deriving clause for every newtype to make this all work nicely. Is there a way to make all types automatically derive everything unless there is an explicit instance declaration otherwise? {-# OPTIONS -fglasgow-exts -fgenerics -fderiving#-} module Blog.Types where data BlogEntry = Entry EpochSeconds Name Email Title Body newtype Name = Name String newtype Title = Title String newtype Body = Body String Isn't that much nicer? -Alex-
Alex Jacobson wrote:
Consider this module for a blog entry that I will want to put in various generic collections that require Ord
{-# OPTIONS -fglasgow-exts #-} module Blog.Types where import Data.Typeable import Data.Generics
data BlogEntry = Entry EpochSeconds Name Email Title Body deriving (Eq,Ord,Read,Show,Typeable)
newtype Name = Name String deriving (Eq,Ord,Read,Show,Typeable) newtype Title = Title String deriving (Eq,Ord,Read,Show,Typeable) newtype Body = Body String deriving (Eq,Ord,Read,Show,Typeable)
It seems really unnecessarily verbose. Having to add the OPTION header AND import Data.Typeable and Data.Generics just to derive Typeable is a beat-down.
It works for me removing the Data.Generics import - I think that's just for generics/deriving Data, which is different from Typeable.
It is even more of a beat-down to have to add a deriving clause for every newtype to make this all work nicely. Is there a way to make all types automatically derive everything unless there is an explicit instance declaration otherwise?
No, not with separate compilation, not in a practical way anyway. And sometimes you don't _want_ a newtype to be an instance of those classes that the inside type is instances of (for abstraction/encapsulation).
{-# OPTIONS -fglasgow-exts -fgenerics -fderiving#-} module Blog.Types where
data BlogEntry = Entry EpochSeconds Name Email Title Body newtype Name = Name String newtype Title = Title String newtype Body = Body String Isn't that much nicer?
A little nicer, but wouldn't you like to get rid of those words "newtype" and duplicate names too? >:) (For your second, desired code sample, I have a feeling this is where DrIFT or Data.Derive are going to come in... I'm not going to mention those external things!) Isaac
(For your second, desired code sample, I have a feeling this is where DrIFT or Data.Derive are going to come in... I'm not going to mention those external things!)
it wouldn't help to get rid of deriving, but perhaps the new 'standalone deriving' might help to separate out all that deriving stuff, keeping the data type definitions themselves less cluttered? http://hackage.haskell.org/trac/ghc/wiki/Status/October06 claus ps why the odd mailing list address?
Actually independent deriving would help a lot but am not sure of the syntax. could it be something like derive (Ord,Eq,Read,Show,Typeable) (BlogEntry Name Title Body Emai) Perhaps this is what Neil Mitchell was suggesting with Derive that I was not understanding. If I can use derive like this without a pre-processor that would be very nice. -Alex- Claus Reinke wrote:
(For your second, desired code sample, I have a feeling this is where DrIFT or Data.Derive are going to come in... I'm not going to mention those external things!)
it wouldn't help to get rid of deriving, but perhaps the new 'standalone deriving' might help to separate out all that deriving stuff, keeping the data type definitions themselves less cluttered?
http://hackage.haskell.org/trac/ghc/wiki/Status/October06
claus
ps why the odd mailing list address?
:: Follow ups to haskell-cafe@ is probably best Hi Alex, {-# OPTIONS_DERIVE --derive=Ord,Eq,Read... #-} That would apply to all definitions in the module, so you don't have to repeat it for each type. You can attach a deriving annotation to each type individually, but that's obviously not what you want.
Actually independent deriving would help a lot but am not sure of the syntax.
could it be something like
derive (Ord,Eq,Read,Show,Typeable) (BlogEntry Name Title Body Emai)
We can already do: $( derive makeOrd ''Name ) Which doesn't require a preprocessor on GHC, using template haskell. I guess the following may work in Template Haskell: $( [derive typ cls | typ <- [makeOrd, makeEq, makeRead, makeShow], typ <- [''BlogEntry, ''Name ...] ) But ask a TH expert for the details! Thanks Neil
Actually independent deriving would help a lot but am not sure of the syntax.
could it be something like
derive (Ord,Eq,Read,Show,Typeable) (BlogEntry Name Title Body Emai)
according to the most recent status report, the syntax is not quite settled yet, so what is in ghc head might still change. more info here: http://haskell.org/haskellwiki/GHC/StandAloneDeriving
Perhaps this is what Neil Mitchell was suggesting with Derive that I was not understanding. If I can use derive like this without a pre-processor that would be very nice.
there are various different methods to help with deriving. i think Neil was referring to Data.Derive: http://www-users.cs.york.ac.uk/~ndm/derive/ claus
Oh, so you want the original behaviour of type declarations back. :) In Haskell 1.0, if you didn't specify any deriving, you got as much derived as possible. I quite liked it, but it was changed. -- Lennart On Tue, 22 May 2007, Alex Jacobson wrote:
Date: Tue, 22 May 2007 19:07:26 -0400 From: Alex Jacobson <alex@alexjacobson.com> To: haskell@CS.YALE.EDU Subject: [Haskell] boilerplate boilerplate
Consider this module for a blog entry that I will want to put in various generic collections that require Ord
{-# OPTIONS -fglasgow-exts #-} module Blog.Types where import Data.Typeable import Data.Generics
data BlogEntry = Entry EpochSeconds Name Email Title Body deriving (Eq,Ord,Read,Show,Typeable)
newtype Name = Name String deriving (Eq,Ord,Read,Show,Typeable) newtype Title = Title String deriving (Eq,Ord,Read,Show,Typeable) newtype Body = Body String deriving (Eq,Ord,Read,Show,Typeable)
It seems really unnecessarily verbose. Having to add the OPTION header AND import Data.Typeable and Data.Generics just to derive Typeable is a beat-down. It is even more of a beat-down to have to add a deriving clause for every newtype to make this all work nicely. Is there a way to make all types automatically derive everything unless there is an explicit instance declaration otherwise?
{-# OPTIONS -fglasgow-exts -fgenerics -fderiving#-} module Blog.Types where
data BlogEntry = Entry EpochSeconds Name Email Title Body newtype Name = Name String newtype Title = Title String newtype Body = Body String Isn't that much nicer?
-Alex-
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
-- Lennart
Hi
{-# OPTIONS -fglasgow-exts #-} module Blog.Types where import Data.Typeable import Data.Generics
data BlogEntry = Entry EpochSeconds Name Email Title Body deriving (Eq,Ord,Read,Show,Typeable)
newtype Name = Name String deriving (Eq,Ord,Read,Show,Typeable) newtype Title = Title String deriving (Eq,Ord,Read,Show,Typeable) newtype Body = Body String deriving (Eq,Ord,Read,Show,Typeable)
First off, never use OPTIONS, use OPTIONS_GHC instead. OPTIONS is the old way of doing it. Secondly, if you add {-# OPTIONS_DERIVE --derive=Eq,Ord,Read,Show,Typeable #-} then running your code through with Derive should give you the magic that you require. Plus it will also work on Hugs, and not require your OPTIONS_GHC anyway. Derive: http://www-users.cs.york.ac.uk/~ndm/derive/ Thanks Neil
I'm not sure I understand how this solves my problem. Its possible that I can use Derive not to need all the newtype declarations at all, but, if I do need them, I'm not sure how Derive reduces the overall amount of boilerplate here. Perhaps I should define a TH function that takes $(newtype' Name String) And converts it to a newtype Name = Name String deriving (Eq,Ord,Read,Show,Typeable) -Alex- Neil Mitchell wrote:
Hi
{-# OPTIONS -fglasgow-exts #-} module Blog.Types where import Data.Typeable import Data.Generics
data BlogEntry = Entry EpochSeconds Name Email Title Body deriving (Eq,Ord,Read,Show,Typeable)
newtype Name = Name String deriving (Eq,Ord,Read,Show,Typeable) newtype Title = Title String deriving (Eq,Ord,Read,Show,Typeable) newtype Body = Body String deriving (Eq,Ord,Read,Show,Typeable)
First off, never use OPTIONS, use OPTIONS_GHC instead. OPTIONS is the old way of doing it.
Secondly, if you add {-# OPTIONS_DERIVE --derive=Eq,Ord,Read,Show,Typeable #-} then running your code through with Derive should give you the magic that you require. Plus it will also work on Hugs, and not require your OPTIONS_GHC anyway.
Derive: http://www-users.cs.york.ac.uk/~ndm/derive/
Thanks
Neil
G'day all. Quoting Alex Jacobson <alex@alexjacobson.com>:
It seems really unnecessarily verbose. Having to add the OPTION header
...which you don't need; this could go on the command line...
It is even more of a beat-down to have to add a deriving clause for every newtype to make this all work nicely.
One neat fix would be for newtype-deriving to work with one of the typeclass synonym extensions (which aren't implemented yet). Cheers, Andrew Bromage
participants (6)
-
ajb＠spamcop.net -
Alex Jacobson -
Claus Reinke -
Isaac Dupree -
Lennart Augustsson -
Neil Mitchell