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
, 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
drawbacks (e.g. performance).
Hmmm, I'm sort of ambivalent at this point.
Looking at the user manual[1], the relevant point
, 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 is that Unlike a deriving declaration
On 12 July 2012 12:33, Andres Löh and...@well-typed.com 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
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 `Rep (T Int
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-Typed LLP, http://www.well
Hi Bas,
On Thu, Jul 12, 2012 at 11:27 AM, Bas van Dijk v.dijk@gmail.com 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. Can you try
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-cafe
) -- 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 newtype deriving to trigger this
behavior
-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 the following
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/savestream
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...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf
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
simo...@microsoft.com wrote:
It's really a bug. I've fixed it in my tree, but I'm
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
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 ronw...@volus.net wrote:
At Igloo's suggestion, it's now a ticket:
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 ronw...@volus.net 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-17
Possible
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
corrupted
...@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:
| Can't make
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
simo...@microsoft.com wrote:
Yes, indeed, see http://hackage.haskell.org/trac/ghc/ticket
Hello,
On Thu, Mar 12, 2009 at 17:02, Bernd Brassel b...@informatik.uni-kiel.dewrote:
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
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' = undefined `ext1Q` (\ (MyJust _) - ())
testExt1' :: ()
testExt1' = useExt1
a = 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
data MyMaybe a = MyJust a | MyNothing deriving (Data,Typeable
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 the
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, and currently the code
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 a proper deriving.
dear GHC
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 is the
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
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 only
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'd suggest
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 partial
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
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
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 the min method
, 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 AddBounds a = MinBound | NoBound a | MaxBound
deriving (Eq, Ord, Read, Show)
I
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 thing here. Standalone deriving
should not cause
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.
Standalone deriving does
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 automatically generated verions.
Standalone
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 argue
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
newtype
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)
correctly gives
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 instances
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 deriving mechanism
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
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-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell
= 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 reflection, I agree. The derived instance would have to be
instance IsIntC Foo where
isInt :: IsIntT Foo
isInt = isIntT
which cannot
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)
Note that (Foo 2) + 2 is an attempt to add a Foo and an Int, which
]:/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 deriving(IsIntC)
x :: IsIntT Foo - Int
x IsIntT = (Foo 2) + 2
IsIntT Foo is a concrete type
ago to solve all the EnumMap performance concerns.)
[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 deriving(IsIntC
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
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 user
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 implementation
) = 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
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 wishes,
| Wolfgang
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
http
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
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
instances too, so you have to write
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
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 mention, that instance decls usually have a
context. I'd be quite happy to require a context
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
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
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
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
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
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
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
$(deriveMyClass
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
$(deriveMyClass
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
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/
I
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
] 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 newtype (any
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
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 one way
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
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 PROTECTED]
http://www.haskell.org
]
[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 modules do
| 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
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)
|
| gives
| E.hs:64
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
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 Char deriving C
. 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 make a fairly general deriving framework, however gmap
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 about
| -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 problems with it. If I
| 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
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
newtype Foo = Foo
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
newtype Foo = Foo Int deriving (Num)
x = show (Foo 5
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
Show
The following datatype declaration would, if possible,
actually be very useful for an application I have in mind:
module Test(V(..)) where
import ST
data V s = forall a . MkV (STRef s a) deriving Eq
Weird! You could never use the reference for anything, because
its type
The correct behaviour would be to let the above pattern match fail
in the case of different types at r1 and r2,
because the left-hand side has to have a typing
with equal types for r1 and r2
induced by the right-hand side ``r1 == r2''.
But now you are assuming that there is an intentional
91 matches
Mail list logo
