| lot of elements in it. Having to do an explicit declaration of deriving
| (Data,Typeable) for each of them is just a tremendous beat-down no
| matter where I do it.
I hate to see you beaten down, Alex. Make a feature request. I don't want to
make promises, but having a well-specified
Hi
On 6/1/07, Alex Jacobson [EMAIL PROTECTED] wrote:
I suppose a deriveAll command from template haskell would work. Is that
really possible?
Asking people who have more knowledge of template haskell, I'm still not sure.
What it would really rely on is:
getDataDeclarationsInCurrentModule
I suppose a deriveAll command from template haskell would work. Is that
really possible?
Asking people who have more knowledge of template haskell, I'm still not sure.
What it would really rely on is:
getDataDeclarationsInCurrentModule :: Q [Dec]
Whether that can be done or not is still not
Actually, standalone deriving doesn't really solve the boilerplate
boilerplate problem. My original complaint here is that I don't want to
explicitly declare a deriving (Data,Typeable) for every type used
somewhere inside a larger type I am using. In this particular case, I
am using SYB to
Claus Reinke wrote:
Actually, standalone deriving doesn't really solve the boilerplate
boilerplate problem. My original complaint here is that I don't want
to explicitly declare a deriving (Data,Typeable) for every type used
somewhere inside a larger type I am using. In this particular case,
Hi Alex,
The problem with Data.Derive is that I now have a pre-processor cycle as
part of my build process. Automatic and universal Data and Typeable
instance deriving should just be built into Haskell.
Not if you use the template haskell support. We don't currently have a
deriveAll command,
I suppose a deriveAll command from template haskell would work. Is that
really possible?
-Alex-
Neil Mitchell wrote:
Hi Alex,
The problem with Data.Derive is that I now have a pre-processor cycle as
part of my build process. Automatic and universal Data and Typeable
instance deriving should
Actually, standalone deriving doesn't really solve the boilerplate
boilerplate problem. My original complaint here is that I don't want to
explicitly declare a deriving (Data,Typeable) for every type used
somewhere inside a larger type I am using. In this particular case, I
am using SYB to
[Redirecting to haskell-cafe; the main list is a good place to open discussions
but not so good for continuing them]
|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
| 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
Indeed... but nothing much is happening at the moment because there's
not been much
| does that help to keep it on the radar?-)
| claus
Indeed! But please modify the wiki. Email has a half life of about 1 day!
S
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Personally I would like
{-# OPTIONS -fglasgow-exts -fgenerics -}
module Blog.Types where
family Usual = (Eq, Ord, Read, Show, Typeable)
data BlogEntry = Entry EpochSeconds Name Email Title Body deriving Usual
newtype Name = Name String deriving Usual
newtype Title = Title String deriving
12 matches
Mail list logo
