Thanks to those who responded to this thread about 'deriving'. My current thoughts are: * I'd be happy to add the ability to separate a 'deriving' clause from its data type declaration, if we can agree syntax (see below). It's fairly easy to do; it makes the language more orthogonal; it's useful. But in fact I think only Martin Sjögren has explicitly said that the feature would be useful.... and every feature has a cost. * I'm not at all keen on making '..deriving( Foo )' mean $(derive 'Foo) or something like that. Just make the TH call yourself! * No one is arguing hard for instance declarations in hi-boot files, so let's leave that for now. Re syntax, the obvious possibility (A) is to add derive( pred1, .., predn ) as a new top-level declaration. E.g. derive( Typeable (T a) ) But that means adding 'derive' as a keyword. Other possibilities: deriving( Typeable (T a) ) -- (B) Re-use 'deriving' keyword The trouble with (B) is that the thing inside the parens is different in this situation than in a data type declaration. Any other ideas? Simon
Simon Peyton-Jones wrote:
derive( Typeable (T a) )
But that means adding 'derive' as a keyword. Other possibilities:
deriving( Typeable (T a) ) -- (B) Re-use 'deriving' keyword
The trouble with (B) is that the thing inside the parens is different in this situation than in a data type declaration.
Any other ideas?
instance Typeable (T a) deriving Cheers Christian
Simon Peyton-Jones wrote:
derive( Typeable (T a) )
But that means adding 'derive' as a keyword. Other possibilities:
deriving( Typeable (T a) ) -- (B) Re-use 'deriving' keyword
The trouble with (B) is that the thing inside the parens is different in this situation than in a data type declaration. Any other ideas?
instance Typeable (T a) deriving
Why not even simply instance Typeable (T a) In other words, derivable classes define default implementations for all their methods. Advantages: (1) no syntax change at all required (2) derived class instances can be partially redefined by the user Disadvantages: (1) Slightly more work in some cases because a complete instance declaration is required. Example: instance Eq a => Eq (T a) Cheers, Andres
On Tue, Oct 19, 2004 at 08:08:49PM +0200, Andres Loeh wrote:
Simon Peyton-Jones wrote:
derive( Typeable (T a) )
But that means adding 'derive' as a keyword. Other possibilities:
deriving( Typeable (T a) ) ... Any other ideas?
instance Typeable (T a) deriving
Why not even simply
instance Typeable (T a)
This already has a meaning in Haskell 98: it means that all class members are undefined. This is sometimes useful. Peace, Dylan
On Tue, 19 Oct 2004 15:33:25 +0100, Simon Peyton-Jones
Thanks to those who responded to this thread about 'deriving'. My current thoughts are:
* I'd be happy to add the ability to separate a 'deriving' clause from its data type declaration, if we can agree syntax (see below). It's fairly easy to do; it makes the language more orthogonal; it's useful.
But in fact I think only Martin Sjögren has explicitly said that the feature would be useful.... and every feature has a cost.
It would be quite useful indeed! The scenarios I have experienced are quite complex, but they occur. Georg
* I'm not at all keen on making '..deriving( Foo )' mean $(derive 'Foo) or something like that. Just make the TH call yourself!
* No one is arguing hard for instance declarations in hi-boot files, so let's leave that for now.
Re syntax, the obvious possibility (A) is to add
derive( pred1, .., predn )
as a new top-level declaration. E.g.
derive( Typeable (T a) )
But that means adding 'derive' as a keyword. Other possibilities: deriving( Typeable (T a) ) -- (B) Re-use 'deriving' keyword
The trouble with (B) is that the thing inside the parens is different in this situation than in a data type declaration.
Any other ideas?
Simon
* I'd be happy to add the ability to separate a 'deriving' clause from its data type declaration, if we can agree syntax (see below). It's fairly easy to do; it makes the language more orthogonal; it's useful.
But in fact I think only Martin Sjögren has explicitly said that the feature would be useful.... and every feature has a cost.
when you said people had asked for this before, I assumed you didn't need further pro arguments, and I didn't want to argue against a feature that would make recursive modules in Haskell less problematic. but here are two examples from the answer I didn't send: - library providers sometimes "forget" to provide useful instances, and "remote deriving" would permit programmers and their users to work around this without waiting for the next release (examples: points were not Show-able in earlier versions of wxHaskell, instances of Data/Typable were missing for the Haskell-AST in earlier versions of ghc&libs, ..). mostly interesting because so many ghc libs these days come as binary distributions, without source. - library users sometimes need instances that library providers don't need (example: HaRe uses Programatica for its Haskell frontend, but uses Strafunski instead of Programatica's built-in generic programming support; for that, we needed the various AST types to be instances of the Data/Typable-equivalents, but we didn't want to change all the Programatica sources involved, which kept evolving independently; DrIFT allowed us to do this, but the recent DrIFT-less support for scrap your boilerplates doesn't provide an equivalent without "remote deriving". mostly interesting to improve modularity, and to avoid changes in externally-maintained code (a form of aspects?-). I guess all DrIFT users would jump on the train if this was combined with user-definable deriving.
deriving( Typeable (T a) ) -- (B) Re-use 'deriving' keyword
avoiding new keywords seems preferable, but don't you need something to attach this to? perhaps the import statement (if you don't define or import it, you can't derive anything)? import Language.Haskell deriving (Typable HsExp, ..)
The trouble with (B) is that the thing inside the parens is different in this situation than in a data type declaration.
depending on syntax, one might also be able to write things that are currently not possible: module M where .. class Odd m b where .. data T a b c = .. import M deriving (Odd (T a Int) Zero,Odd (T Bool b) (Succ Zero)) without support for user-defined derive, the whole idea is a lot less interesting, though Data/Typable and Read/Show probably account for two major application areas. still, will non-variable parameters be permitted, and do we know what that means? cheers, claus
participants (6)
-
Andres Loeh -
Christian Maeder -
Claus Reinke -
dpt＠lotus.bostoncoop.net -
Georg Martius -
Simon Peyton-Jones