I just noticed that if you derive Real for a Ratio.Rational newtype,
you get a warning:
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
import qualified Data.Ratio as Ratio
newtype X = X Ratio.Rational deriving (Eq, Ord, Num, Real)
You get a warning:
: Warning:
Call of toRational :: Rational
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
>> drawbac
or 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
> 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
-
On 12 July 2012 12:33, Andres Löh wrote:
> Your example compiles for me with HEAD (but fails with 7.4.1 and
> 7.4.2, yes). I've not tested if it also "works".
Great, I will wait for a new release then.
Bas
___
Glasgow-haskell-users mailing list
Glasgo
Hi Bas,
On Thu, Jul 12, 2012 at 11:27 AM, Bas van Dijk wrote:
> Hi,
>
> I'm hitting on an issue when deriving Generic for an associated data type:
>
> ...
>
> The GHC trac seems to be down. Is this a known issue?
>
Yes, and it's supposed to be fixed in HEAD.
Hi Bas.
> I'm hitting on an issue when deriving Generic for an associated data type:
[...]
Your example compiles for me with HEAD (but fails with 7.4.1 and
7.4.2, yes). I've not tested if it also "works".
Cheers,
Andres
--
Andres Löh, Haskell Consultant
Well-Typ
Hi,
I'm hitting on an issue when deriving Generic for an associated data type:
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE DeriveGeneric #-}
import GHC.Generics
class Foo a where
data T a :: *
instance Foo Int where
data T Int = Bla deriving Generic
Couldn't match type `
Hello,
Given the following program:
---
{-# LANGUAGE DeriveDataTypeable, TypeFamilies #-}
import Data.Typeable
class C a where
data T a :: *
data MyType1 = MyType1 deriving Typeable
data MyType2 = MyType2 deriving Typeable
instance
| iterIO uses mkTyCon for the simple reason that ((Typeable t, Typeable
| m) => Iter t m) is Typeable1 and there is no automatic way of deriving
| Typeable1.
This email is triggered by a thread on Haskell Cafe about changes to the
Typeable class
http://www.mail-archive.com/haskell-c
| To: glasgow-haskell-users@haskell.org
| Subject: Newtype deriving mixing up types
|
| Hello!
|
| I attach a program which I suspect demonstrates a bug in GHC. The important
| lines are:
|
|showType :: forall a . Expr a -> String
|showType (Lit _) = show (typeOf (undefined :: a))
|
|
it mk :: Expr BOOL) -- Prints "Main.BOOL" (correct)
test1 and test2 give different results, even though showType shouldn't
be able to tell them apart. It seems that the Typeable context packed
with the Lit constructor is wrong in test2.
I had to use two extra classes and newt
ow-haskell-users@haskell.org
| Subject: standalone binary deriving
|
| compiling the following fragment in ghci
|
| {-# LANGUAGE StandaloneDeriving #-}
|
| import Data.Binary (Binary)
|
| newtype Pair a b = Pair (a,b)
| deriving instance (Binary a, Binary b) => Binary (Pair a b)
|
| results in
compiling the following fragment in ghci
{-# LANGUAGE StandaloneDeriving #-}
import Data.Binary (Binary)
newtype Pair a b = Pair (a,b)
deriving instance (Binary a, Binary b) => Binary (Pair a b)
results in the following message:
Prelude> :load "/Users/catbee/Documents/dev/haskell
The standalone deriving decl you need is the one for (Data (a :+: b)), not for
Expr
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Ron Alford
| Sent: 12 April 2010 11:09
| To: Simon Peyton
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 AM, Simon Peyton-Jones
wrote:
> It's really a bug. I've fixed it in my tree, but I&
if it's important to you.
it's bit of an exotic case because of the higher-kindedness so I don't think
it'll bite too man people
There's a good workaround: use "standalone deriving".
You
| -Original Message-
| From: glasgow-haskell-users-boun..
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:
...
_
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:
baddata.hs:33:14:
No instances for (Data Const, Data Var)
arising from the 'deriving' clause of a data type declaration
at baddata.hs:33:14-
Hello guys,
are you following this Haskell Cafe thread:
<http://www.mail-archive.com/haskell-c...@haskell.org/msg72300.html>
Seems that you can do ugly things with GHC’s current implementation of
generalized newtype deriving. For example, you can easily construct sets with
cor
If it's easy I think just generating the code and let the type checker
report any problems would be a great thing for standalone deriving.
-- Lennart
On Tue, Apr 14, 2009 at 10:10 AM, Simon Peyton-Jones
wrote:
> Yes, indeed, see http://hackage.haskell.org/trac/ghc/ticket/3012
>
>
-boun...@haskell.org] On
Behalf Of
| Norman Ramsey
| Sent: 14 April 2009 05:28
| To: hask...@haskell.org
| Subject: [Haskell] deriving Show for GADT?
|
| I've got a fairly large GADT for which I wished to use
| deriving (Show)
| but I got a mysterious error message:
|
| Exp.hs:13:11:
| Ca
Hello,
On Thu, Mar 12, 2009 at 17:02, Bernd Brassel wrote:
> José Pedro Magalhães wrote:
> > Hi Bernd,
> >
> > I guess this might be the same issue reported some time ago (
> > http://thread.gmane.org/gmane.comp.lang.haskell.generics/53/focus=54):
> the
> > derived instances of Data do not define
José Pedro Magalhães wrote:
> Hi Bernd,
>
> I guess this might be the same issue reported some time ago (
> http://thread.gmane.org/gmane.comp.lang.haskell.generics/53/focus=54): the
> derived instances of Data do not define dataCast1. If you define your own
> instance of Data for MyMaybe and add
> a -> ()
> > useExt1 = undefined `ext1Q` (\ (Just _) -> ())
>
> > testExt1 :: ()
> > testExt1 = useExt1 (Just ())
>
> As I expected, testExt1 yields ()
>
> But when I define my own version of Maybe and derive the Data/Typeable
> instances
>
>
st ())
As I expected, testExt1 yields ()
But when I define my own version of Maybe and derive the Data/Typeable
instances
> data MyMaybe a = MyJust a | MyNothing deriving (Data,Typeable)
the corresponding test
> useExt1' :: Data a => a -> ()
> useExt1' = unde
o derive an instance Functor T:
- First to determine whether the deriving should be allowed at all
(checkSideConditions)
- Then to determine the constraints needed (mk_data_eqn)
- Finally to make the body of the instance (gen_Functor_binds)
This seems a bit redundant, an
Hello Neil,
Thursday, June 5, 2008, 8:54:51 PM, you wrote:
>> PS Why isn't Functor derivable?
> Derive can do it: http://www.cs.york.ac.uk/~ndm/derive
> I believe that Twan (the author of Functor deriving in Derive) is
> trying to get this suggested for Haskell' as
The issue is more than just efficiency. It's vital that these improving
values get evaluated as little as possible. In my use for functional
reactivity, they represent the times of future event occurrences.
Your (<=)-via-min idea might work in some cases, though useful pointer
equality can be pr
Christian Maeder wrote:
> Conal Elliott wrote:
>> The type argument I ran into trouble with represents a value as a list
>> of increasing lower bounds, ending in the exact value. min produces
>> lower bounds from lower bounds and so is immediately productive before
>> even knowing which argument i
Conal Elliott wrote:
> The type argument I ran into trouble with represents a value as a list
> of increasing lower bounds, ending in the exact value. min produces
> lower bounds from lower bounds and so is immediately productive before
> even knowing which argument is the lesser one.
Is this on
Oh -- partial & partial. Thanks. I was pretty puzzled there.
The type argument I ran into trouble with represents a value as a list of
increasing lower bounds, ending in the exact value. min produces lower
bounds from lower bounds and so is immediately productive before even
knowing which argum
Conal Elliott wrote:
> AddBounds makes total orders from total orders. It just adds new least
> and greatest elements.
>
> The problem with the derived instance is that it doesn't exploit the
> potential laziness of min on 'a'. Because of their types, min it can
> produce partial info from parti
lt;=) and compares cannot.
- Conal
On Thu, Mar 20, 2008 at 2:00 AM, Christian Maeder <[EMAIL PROTECTED]>
wrote:
> Conal Elliott wrote:
> > I have an algebraic data type (not newtype) that derives Ord:
> >
> > data AddBounds a = MinBound | NoBound a | MaxBound
>
Conal Elliott wrote:
> I have an algebraic data type (not newtype) that derives Ord:
>
> data AddBounds a = MinBound | NoBound a | MaxBound
> deriving (Eq, Ord, Read, Show)
The class Ord is not suited for partial orders. If you write your own
Ord instances anyway, I&
`max` _ = MaxBound
Cheers, - Conal
On Wed, Mar 19, 2008 at 2:35 PM, Duncan Coutts <[EMAIL PROTECTED]>
wrote:
>
> On Wed, 2008-03-19 at 14:11 -0700, Conal Elliott wrote:
> > I have an algebraic data type (not newtype) that derives Ord:
> >
> > data AddBou
On Wed, 2008-03-19 at 14:11 -0700, Conal Elliott wrote:
> I have an algebraic data type (not newtype) that derives Ord:
>
> data AddBounds a = MinBound | NoBound a | MaxBound
> deriving (Eq, Ord, Read, Show)
>
> I was hoping to get a min method defined in terms of
I have an algebraic data type (not newtype) that derives Ord:
data AddBounds a = MinBound | NoBound a | MaxBound
deriving (Eq, Ord, Read, Show)
I was hoping to get a min method defined in terms of the min method of the
type argument (a). Instead, I think GHC is producing something
son wrote:
> > When you want automated deriving of show/read etc., you need all the
> > components of your type also to be instances of show/read but you won't
> > want to *require* them to be automatically generated verions.
> >
> > Standalone deriving does the wrong
duncan.coutts:
> On Tue, 2007-11-20 at 19:18 -0500, Alex Jacobson wrote:
> > When you want automated deriving of show/read etc., you need all the
> > components of your type also to be instances of show/read but you won't
> > want to *require* them to be autom
On Tue, 2007-11-20 at 19:18 -0500, Alex Jacobson wrote:
> When you want automated deriving of show/read etc., you need all the
> components of your type also to be instances of show/read but you won't
> want to *require* them to be automatically generated verions.
>
> Stan
Simon Peyton-Jones wrote:
Well it's debatable. Suppose we have
newtype Foo = MkFoo String deriving( Num )
Do you want to generate
instance Num String => Num Foo
?
Personally, I think I would like that -- along with a warning message.
It makes it clearer to me that I can do
Well it's debatable. Suppose we have
newtype Foo = MkFoo String deriving( Num )
Do you want to generate
instance Num String => Num Foo
? I suspect not -- usually we generate an error message right away if we need
a Num String instance and one is not available.
Now you could ar
Hello,
I noticed there is a difference in generalized newtype deriving between
6.6 and 6.8. In GHC 6.4.1 the following:
> {-# LANGUAGE GeneralizedNewtypeDeriving #-}
>
> import Control.Monad.Error
>
> newtype MyMonad m a = MyMonad (m a)
> deriving (Monad, MonadError String
I'm running ghc-6.7.20070802 and getting a new error message that didn't
show up with ghc-6.6. Code:
-- | Pairing for unary type constructors.
newtype Pair1 f g a = Pair1 {unPair1 :: (f a, g a)}
deriving (Eq, Ord, Show)
Error message:
src/Data/Tupler.hs:26:0:
No
Simon Peyton-Jones wrote:
Generally speaking GHC will inline *across* modules just as much as
it does *within* modules, with a single large exception.
If GHC sees that a function 'f' is called just once, it inlines it
regardless of how big 'f' is. But once 'f' is exported, GHC can
never se
Right. There are two things going on in this thread. First, when you say
newtype T = MkT Int
then T and Int are distinct types. Adding a deriving( whatever ) doesn't
change that fact. Earlier messages make this point.
The second is that GHC's current "newtype derivin
, 2007 at 12:03:41PM +0100, Chris Kuklewicz wrote:
Stefan O'Rear wrote:
On Tue, Mar 27, 2007 at 11:32:29AM +0100, Chris Kuklewicz wrote:
Stefan O'Rear wrote:
newtype Foo = Foo Int deriving(IsIntC)
Note that (Foo 2) + 2 is an attempt to add a Foo and an Int,
which cannot
possibly c
On Wed, Mar 28, 2007 at 12:03:41PM +0100, Chris Kuklewicz wrote:
> Stefan O'Rear wrote:
> > On Tue, Mar 27, 2007 at 11:32:29AM +0100, Chris Kuklewicz wrote:
> >> Stefan O'Rear wrote:
>
> >>>> newtype Foo = Foo Int deriving(IsIntC)
> >>>&
where isInt :: IsIntT a
>>> instance IsIntC Int where isInt = IsIntT
>>>
>>> newtype Foo = Foo Int deriving(IsIntC)
>
> I think newtype deriving should be rejected in this case. Maybe this is
> the real problem here?
>
> Best regards
> Tomek
On reflectio
Int where isInt = IsIntT
> >
> > newtype Foo = Foo Int deriving(IsIntC)
I think newtype deriving should be rejected in this case. Maybe this is
the real problem here?
Best regards
Tomek
___
Glasgow-haskell-users mailing list
Glasgow-haskell-u
Stefan O'Rear wrote:
> On Tue, Mar 27, 2007 at 11:32:29AM +0100, Chris Kuklewicz wrote:
>> Stefan O'Rear wrote:
>>>> newtype Foo = Foo Int deriving(IsIntC)
>>>>
>
>> Note that (Foo 2) + 2 is an attempt to add a Foo and an Int, which cannot
Stefan O'Rear:
> They are the same type, and I have Curry-Howard proof of this fact.
If that's the case, then it begs the question why you'd bother defining
Foo in the first place. How would this solve EnumMap performance
concerns?
I am under the impression that newtypes are *defined* to be disti
> class IsIntC a where isInt :: IsIntT a
> >> instance IsIntC Int where isInt = IsIntT
> >>
> >> newtype Foo = Foo Int deriving(IsIntC)
> >>
> >> x :: IsIntT Foo -> Int
> >> x IsIntT = (Foo 2) + 2
>
> IsIntT Foo is a concrete type.
> IsIntT
rns.)
>
> [EMAIL PROTECTED]:/tmp$ cat A.lhs
>> {-# OPTIONS_GHC -fglasgow-exts #-}
>>
>> data IsIntT x where IsIntT :: IsIntT Int
>>
>> class IsIntC a where isInt :: IsIntT a
>> instance IsIntC Int where isInt = IsIntT
>>
>> newtype Foo = Foo Int
> {-# OPTIONS_GHC -fglasgow-exts #-}
>
> data IsIntT x where IsIntT :: IsIntT Int
>
> class IsIntC a where isInt :: IsIntT a
> instance IsIntC Int where isInt = IsIntT
>
> newtype Foo = Foo Int deriving(IsIntC)
>
> x :: IsIntT Foo -> Int
> x IsIntT = (Foo 2) + 2
&g
GHC 6.4.1 accepts your declaration but generates a useless insatance decl.
GHC 6.6 will still let you generate the same instance, but only if you use
another type variable, for instance
deriving (MonadReader x)
GHC 6.6's behaviour is defined by the appropriate section of the
e able to use it, because the
instance in Control.Monad.Reader looks like:
instance (Monad m) => MonadReader r (ReaderT r m) where
You intended to write
deriving (MonadReader r)
GHC 6.4.1 accepts your declaration but generates a useless insatance decl.
GHC 6.6 will still let you g
Hi,
The following code compiles with GHC 6.4.2, but does not typecheck
with GHC HEAD pulled on Sunday.
module CompilerMonad where
import Control.Monad
import Control.Monad.Reader
import Control.Monad.Error
newtype CompilerError = CE String deriving Error
newtype CM r a = CM (ReaderT r
The thread about "stand-alone" deriving is long-ish now, so I have summarised
the issues here:
http://haskell.org/haskellwiki/GHC/StandAloneDeriving
Perhaps those who are interested can add their thoughts? Bjorn is busy at the
moment, but I think he'll get back to the im
forall c. (C c, Show c) => CObj c
deriving (C) ?
->
?
Or is this already possible?
Marc Weber
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
f Wolfgang Jeltsch
| Sent: 10 July 2005 18:43
| To: GHC Users ML
| Subject: option for enabling generalized deriving for newtypes
|
| Hello,
|
| isn't there an option for enabling just generalized deriving for
newtypes
| without enabling all this other stuff by using -fglasgow-exts?
|
| Best wis
Hello,
isn't there an option for enabling just generalized deriving for newtypes
without enabling all this other stuff by using -fglasgow-exts?
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
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( Typeabl
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 decl
(==) and (/=) in Eq.
I would then vote for
> It'd have to be
> instance Typeable (T a) deriving
Perhaps it would be not much harder to allow
instance Show MyChar deriving where
showList = ...
to partially override derived functions as well.
> The trouble is, as you men
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
>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 w
ive all
methods".
It'd have to be
instance Typeable (T a) deriving
or
derive instance Typeable (T a)
Something to clearly signal the magic.
The trouble is, as you mention, that instance decls usually have a
context. I'd be quite happy to require a context in these derived
insta
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 cur
>* 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 o
> 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
> >
> >T
> * 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)
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
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 t
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 loo
> 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
>> cl
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
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
d
a deriving TTypeable
generates the instance:
instance TTypeable a al => TTypeable (Fred a) (NCons (N3 (N4 (N5
Nil))) (TCons al Nil))
If you are happy to live on the edge a bit (which you seem to be happy
with, considering that you're playing with GHC CVS ;), Template Haskell
might be on
>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 deriv
TECTED] On Behalf Of MR K P SCHUPKE
| Sent: 13 October 2004 14:06
| To: [EMAIL PROTECTED]
| Subject: deriving...
|
|
| What is the situation with deriving?
|
| Some instances can be derived automatically for both data/newtype
(built in)?
|
| Some instances cen be derived automatically for ne
What is the situation with deriving?
Some instances can be derived automatically for both data/newtype (built in)?
Some instances cen be derived automatically for newtype (any)?
You used to be able to define functions useing {|+|} and {|*|} (or similar)
that could be derived for both data and
ECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of MR K P SCHUPKE
| Sent: 08 October 2004 14:26
| To: [EMAIL PROTECTED]
| Subject: deriving
|
|
| How is deriving coded in ghc. For example the "Typeable" class, when
in
| the compilation sequence is this expanded? Which modul
How is deriving coded in ghc. For example the "Typeable" class, when in
the compilation sequence is this expanded? Which modules do this, and
which functions?
Keean.
___
Glasgow-haskell-users mailing list
[EMAIL PROTE
| 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'
|
m!
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of John Meacham
| Sent: 02 June 2004 21:53
| To: [EMAIL PROTECTED]
| Subject: deriving Typeable
|
| newtype Y e = Y { unY :: (e (Y e)) }
| deriving(Data,Typeable,Show,Read,Eq)
|
| giv
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
lf Of Wolfgang
| Jeltsch
| Sent: 21 March 2004 17:55
| To: The Haskell Mailing List
| Subject: [Haskell] deriving with newtypes
|
| Hello,
|
| I'm trying to use GHC's deriving mechanism for newtypes in the
following way:
| class C a b
| instance C [a] Char
| newtype T = T Cha
a module I made to warmup with TH. Unfortunately, this was back
with 5.05 and I'm pretty sure the names and data structures have been
changed. Hopefully, it's a relatively decent example of how to do this,
it did seem to work at the time. When I work with TH again, I'd
like to
Hi,
is any workable example code for using Template Haskell to generate
instance declarations available, eg the function `genEq' mentioned in
the Template Haskell paper?
Greetings,
Carsten
--
Carsten Schultz (2:40, 33:47), FB Mathematik, FU Berlin
http://carsten.fu-mathe-team.de/
PGP/GPG key o
It's a bug. Thank you
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
| On Behalf Of George Russell
| Sent: 11 June 2003 13:07
| To: [EMAIL PROTECTED]
| Subject: Conditions on deriving Typeable
|
| Please satisfy my curiosity, what is it
Please satisfy my curiosity, what is it about
data WrappedDisplayType = forall displayType .
DisplayType displayType => WrappedDisplayType displayType
deriving (Typeable)
that causes GHC 6.0 to utter
DisplayTypes.hs:135:
Can't make a derived instance of `
tice the bug.
Simon
| -Original Message-
| From: Hal Daume III [mailto:hdaume@;ISI.EDU]
| Sent: 02 October 2002 18:58
| To: GHC Users Mailing List
| Subject: deriving weirdness on newtypes
|
| So I love the fact that I can derive anything I want on
| newtypes. However, there seem to be pro
| 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 com
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 &q
1 - 100 of 106 matches
Mail list logo
