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
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 messa
-Jones
| Cc: glasgow-haskell-users
| Subject: Re: Deriving regression or bad code?
|
| I was getting a similar error with standalone deriving (already
| attached to that bug), but I didn't try it through-out. I'll let you
| know how it goes.
|
| -Ron
|
|
| On Mon, Apr 12, 2010 at 6:01
haskell.org [mailto:glasgow-haskell-
> | users-boun...@haskell.org] On Behalf Of Ron Alford
> | Sent: 10 April 2010 22:33
> | To: glasgow-haskell-users
> | Subject: Re: Deriving regression or bad code?
> |
> | Just for fun, I tried it on 6.12.1.20100330 with the same result.
> |
.@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Ron Alford
| Sent: 10 April 2010 22:33
| To: glasgow-haskell-users
| Subject: Re: Deriving regression or bad code?
|
| Just for fun, I tried it on 6.12.1.20100330 with the same result.
| Does anyone have a workaround? Oth
Just for fun, I tried it on 6.12.1.20100330 with the same result.
Does anyone have a workaround? Otherwise I need to revert to 6.10.
-Ron
On Thu, Apr 8, 2010 at 10:35 AM, Ron Alford wrote:
> At Igloo's suggestion, it's now a ticket:
> http://hackage.haskell.org/trac/ghc/ticket/3965
>
> -Ron
>
>
At Igloo's suggestion, it's now a ticket:
http://hackage.haskell.org/trac/ghc/ticket/3965
-Ron
On Thu, Apr 8, 2010 at 1:39 AM, Ron Alford wrote:
> I've attached the simplest example of my code that used to compile in
> GHC 6.10 now gives the error in GHC 6.12.1:
...
_
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 Type
As posted on this list, there is template-haskell code to do:
>$(derive [| data Foo = Foo |])
You can also get the type of Foo in TH by doing:
dummy :: Foo
dummy = undefined
$(derive2 "dummy")
and the code for derive2 reify's the argument, which then gives the
reflected type... so the example c
On Tue, 19 Oct 2004 15:33:25 +0100, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
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
> | Why not even simply
> |
> | instance Typeable (T a)
> |
> | In other words, derivable classes define default
> | implementations for all their methods.
>
> But that has an existing meaning! It means "use the default methods for
> all methods of the class". Which is not the same as "derive
deriving instances will only work for
a) known/builtin classes (like Typeable, Eq, Show, etc)
b) datatypes T that are defined elsewhere using data (or newtype) where
the corresponding deriving clause is missing.
HTH Christian
MR K P SCHUPKE wrote:
instance Typeable (T a)
Forgive my stupid questi
>instance Typeable (T a)
Forgive my stupid question, but why? What will deriving instances do?
Questions that spring to mind are:
1) How will the deriviation of instances be defined... If instances
are the same for all types then this is just the current default
method. If not then this will nee
| Why not even simply
|
| instance Typeable (T a)
|
| In other words, derivable classes define default
| implementations for all their methods.
But that has an existing meaning! It means "use the default methods for
all methods of the class". Which is not the same as "derive all
methods".
It'
On Tue, 19 Oct 2004 15:56:01 +0100 (BST), MR K P SCHUPKE
<[EMAIL PROTECTED]> wrote:
> > * I'm not at all keen on making '..deriving( Foo )' mean
> > $(derive 'Foo) or something like that. Just make the TH
> > call yourself!
>
> The current situation is that the code that generates the derived
>* 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
>
> 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
> * I'm not at all keen on making '..deriving( Foo )' mean
> $(derive 'Foo) or something like that. Just make the TH
> call yourself!
The current situation is that the code that generates the derived
instances is hard coded into the compiler (TcDeriv.hs) is it not
better to allow the derived
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 decl
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;
Okay so that does the deriving... How are you deriving the constraints?
(in the ghc code there is
some equaion expansion, where it finds the fixed point).
Still the main point was that it would be nice to seamlessly integrate
this... Surely it wouldn't take much
to get the compiler to look for
> Keean Schupke <[EMAIL PROTECTED]> writes:
>
>> Yes, I could quite easily write the generator in TemplateHaskell (have
>> played with it before)
>> _but_ I don't like the $(xxx) syntax... Perhaps if Simon could be
>> persuaded to allow deriving
>> clauses to be defined in TH?
>>
>> data X x = X x
MR K P SCHUPKE <[EMAIL PROTECTED]> writes:
>>Check out Ulf Norell's IOHCC submission, his DeriveData.hs module does this,
>
> Do you have a link?
Yes, it's here: http://www.scannedinavian.org/iohcc/succzeroth-2004/ulfn.tar.gz
--
Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/
"
>Check out Ulf Norell's IOHCC submission, his DeriveData.hs module does this,
Do you have a link?
Keean.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Keean Schupke <[EMAIL PROTECTED]> writes:
> Yes, I could quite easily write the generator in TemplateHaskell (have played with
> it before)
> _but_ I don't like the $(xxx) syntax... Perhaps if Simon could be persuaded to allow
> deriving
> clauses to be defined in TH?
>
> data X x = X x
> $(deri
Yes, I could quite easily write the generator in TemplateHaskell (have
played with it before)
_but_ I don't like the $(xxx) syntax... Perhaps if Simon could be
persuaded to allow deriving
clauses to be defined in TH?
data X x = X x
$(deriveMyClass (reify X))
could perhaps be defined from
data X
On 13/10/2004, at 10:02 AM, MR K P SCHUPKE wrote:
Okay, I see the Generic type class stuff does not support multi
parameter type classes. I guess I am stuck - any suggestions as to
how best do this?
I wish to be able to derive type level labels for datatypes, like
the following:
data Fred a = Fred
>look at the user manual.
Okay, I see the Generic type class stuff does not support multi
parameter type classes. I guess I am stuck - any suggestions as to
how best do this?
I wish to be able to derive type level labels for datatypes, like
the following:
data Fred a = Fred a deriving TTypea
(I assume you mean GHC.)
Don't look at the compiler, look at the user manual. That describes
what's supported. I have no current plans to withdraw any of the
current support.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Beha
It's all done by the module TcDeriv, which exports one function,
tcDeriving, which does all the work. It generates source-code syntax
for derived classes. You can grep for where tcDeriving is called (one
place in TcInstDcls).
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto
| newtype Y e = Y { unY :: (e (Y e)) }
| deriving(Data,Typeable,Show,Read,Eq)
|
| gives
| E.hs:64:
| Can't make a derived instance of `Typeable (Y e)'
| (`Y' is parameterised over arguments of kind other than `*')
| When deriving instances for type `Y'
|
| Is there any way around
You can just write the instance of Typeable by hand
instance Typeable1 e => Typeable (Y e) where ...
(Use the instances in the library as a guide.)
Yes, GHC could do this for you, but it would then stumble when e had kind ((*->*) ->
*). We need kind polymorphism!
Simon
| -Original
Hal
I have fixed this bug in the HEAD.
The fix is more than a tiny one, so I'm inclined to leave it as a know
bug in 5.02.2. It'd cost me another few hours to patch it into the
5.02 branch. I don't think this is a widely-used feature, yet. Even
John Hughes didn't notice the bug.
Simon
| ---
| newtype Foo = Foo Int deriving (Num)
| instance Show Foo where { show = undefined }
|
| then, the value of 'show (Foo 5)' is undefined, but the value of 'show
| (5::Foo)' is "5". definately *WRONG*.
You're right. This is all a bit more complicated than I (or John H)
thought. Thin
Hal Daume III <[EMAIL PROTECTED]> writes:
> So I love the fact that I can derive anything I want on
> newtypes. However, there seem to be problems with it. If I write:
>
> newtype Foo = Foo Int deriving (Show)
> x = show (Foo 5)
>
> Then x is "Foo 5"
>
> However, if I do
>
> new
> And the Simon's warning is for remembering that the effect is about as
> if one sets these instances manually.
>
> Do i understand correct?
My point was merely that it's easy to forget how much code is needed for an
instance of Show or Read, since it's easy (too easy :-) to stick 'deriving
Sh
36 matches
Mail list logo
