- Haskell-Cafe - Haskell.org

Instances of constrained datatypes
by Arjun Guha 08 Apr '05

08 Apr '05

This is a contrived example, but contains the essence of what I'd like to do. Suppose I have this datatype: > data (Eq v) => EqList v = EqList [v] I'd like to make it an instance of Functor. However, fmap takes an arbitrary function of type a -> b. I need an Eq constraint on a and b. Is there any way to do this without creating my own `EqFunctor' class with explicitly-kinded quantification: > class (Eq a) => EqFunctor (f :: * -> *) a where > eqfmap:: (Eq b) => (a -> b) -> f a -> f b Thanks. -Arjun

4 7

Re: Instances of constrained datatypes
by John Hughes 07 Apr '05

07 Apr '05

> > >This is a contrived example, but contains the essence of what I'd like >to do. Suppose I have this datatype: > > > data (Eq v) => EqList v = EqList [v] > >I'd like to make it an instance of Functor. However, fmap takes an >arbitrary function of type a -> b. I need an Eq constraint on a and >b. Is there any way to do this without creating my own `EqFunctor' >class with explicitly-kinded quantification: > > > class (Eq a) => EqFunctor (f :: * -> *) a where > > eqfmap:: (Eq b) => (a -> b) -> f a -> f b > >Thanks. > >-Arjun > > > > > I wrote a paper proposing an extension to allow this, published at the Haskell Workshop in 1999. Here's the link: http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps Getting the right dictionaries to the right place involves adding a concept of well-formed types, which perhaps is why it hasn't been taken up by the Simons... John Hughes

1 0

RE: [Haskell-cafe] Instances of constrained datatypes
by Simon Peyton-Jones 07 Apr '05

07 Apr '05

I believe that you may find these papers relevant: "Bulk types with class" http://research.microsoft.com/%7Esimonpj/Papers/collections.ps.gz "Restricted data types" http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps John's paper mentions that it would be great if the constraint simplifier could generate recursive dictionaries --- and indeed GHC's constraint simplifier now does exactly that. So you can apply his technique. I'm not 100% certain this addresses your problem, but I think it does. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Keean Schupke | Sent: 07 April 2005 09:30 | To: Keean Schupke | Cc: haskell-cafe(a)haskell.org | Subject: Re: [Haskell-cafe] Instances of constrained datatypes | | One way to do roughly what you want is to pass the dictionary yourself: | | >data EqDict a = EqDict { | > leq :: a -> a -> Bool } | > | >data EqList a = EqList (EqDict a) [a] | > | >test :: EqList a -> EqList a -> Bool | >test (EqList dict (a0:as)) (EqList _ (b0:bs)) = (leq dict) a0 b0 | | In this way the definition of equality on elements of type 'a' is passed | with the list type, so it can be used wherever the list type is used, | without requiring extra constraints. | | Keean. | | Keean Schupke wrote: | | > I think it is more a problem of imlpementation than one of what is | > desirable. A Constrained data type: | > | > data (Eq v) => EqList v = EqList [v] | > | > The problem is how to get the dictionary for the class Eq to the | > application site: | > | > f :: EqList v -> EqList v | > f (EqList (u0:us)) (EqList (v0:vs)) | v0 == u0 = ... | > | > Which of course does not work... the constraint needs to be in the | > function | > type signature: | > | > f :: Eq v => EqList v -> EqList v | > | > Things are worse though, as even functions that use no methods of Eq will | > require the constraint. | > | > The constraint on the data type does not stop you construction EqLists | > from | > non Eq members... of course this gets detected the moment you try and | > use it | > in a constrained function. | > | > | > In other words using the constraint in the data type does nothing... | > you may as well just do: | > | > f :: Eq v => [v] -> [v] | > | > | > Infact I believe it was decided to remove the feature from Haskell98 | > entirely, but there was apparently some use for the 'syntax' although | > with a different effect. | > | > Keean. | > | > Cale Gibbard wrote: | > | >> I don't believe you can, but it would be nice. There are certain | >> types, such as Set, where it's not really possible to just remove the | >> constraint from the data declaration, and yet it would be nice if sets | >> could be instances of Monad and Functor. Currently, to be an instance | >> of Functor or Monad, your type has to be a functor defined on the | >> whole category of types. | >> | >> Could this issue be fixed somehow? Constrained instances would make | >> various typeclass-based libraries more applicable. What would it break | >> to allow instances where the types of functions defined by the | >> typeclass are further restricted? I suppose that checking that types | >> are correct becomes more difficult and non-local, because functions | >> which are defined using the typeclass won't already have that | >> constraint for obvious reasons. Still, the constraint is in the | >> instance, which must be around when the functions actually get | >> applied. There are probably bad interactions with the module system, | >> but I'm not certain. | >> | >> People must have talked about this before... was a consensus reached | >> that I'm not aware of? | >> | >> - Cale | >> | >> On Apr 6, 2005 2:10 AM, Arjun Guha <guhaarju(a)grinnell.edu> wrote: | >> | >> | >>> This is a contrived example, but contains the essence of what I'd like | >>> to do. Suppose I have this datatype: | >>> | >>> > data (Eq v) => EqList v = EqList [v] | >>> | >>> I'd like to make it an instance of Functor. However, fmap takes an | >>> arbitrary function of type a -> b. I need an Eq constraint on a and | >>> b. Is there any way to do this without creating my own `EqFunctor' | >>> class with explicitly-kinded quantification: | >>> | >>> > class (Eq a) => EqFunctor (f :: * -> *) a where | >>> > eqfmap:: (Eq b) => (a -> b) -> f a -> f b | >>> | >>> Thanks. | >>> | >>> -Arjun | >>> | >> | > | > _______________________________________________ | > Haskell-Cafe mailing list | > Haskell-Cafe(a)haskell.org | > http://www.haskell.org/mailman/listinfo/haskell-cafe | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Strange breakage after Hugs upgrade
by John Goerzen 05 Apr '05

05 Apr '05

Hi, I have this code: class (Show a) => HVFSStat a where ... vModificationTime :: a -> EpochTime ... class (Show a) => HVFS a where ... vGetModificationTime :: a -> FilePath -> IO ClockTime ... vGetModificationTime fs fp = do s <- vGetFileStatus fs fp return $ TOD (fromIntegral (withStat s vModificationTime)) 0 This works fine in Hugs 200311, but in Hugs 20050308, I get: ERROR "/home/jgoerzen/tree/projects/missingh/MissingH/IO/HVFS.hs":198 - Implementation of vGetModificationTime requires extra context *** Expected type : HVFS a => a -> FilePath -> IO ClockTime *** Missing context : Integral CTime I can't figure out what's going on; the type of the expression (withStat s vModificationTime) is EpochTime, and I don't understand why Hugs would have decided to break this code. Thanks, John

1 2

Hugs CPP macros?
by John Goerzen 05 Apr '05

05 Apr '05

Hi, I need to use some conditional compilation in MissingH so that it can work with GHC 6.2, 6.4, and the old/new Hugs libraries. I found the appropriate macros to test for with ghc, but I can't for Hugs. The cpphs-hugs doesn't even define __HUGS__. It seems that only hugs-hc and ffihugs define that, but I don't need them. And where __HUGS__ is defined, it isn't defined with a version number, so it doesn't help me differentiate the Hugs versions. Any suggstions? Thanks, John

1 0

Data.Map
by Gracjan Polak 03 Apr '05

03 Apr '05

Hi all, As I tried to convert some of my code to newer libraries comming with GHC 6.4, I would like to share two things with you: I noticed that there are two functions missing: deleteList and insertList. The first one is easy with foldl: deleteList list map = foldl (flip Data.Map.delete) map list Second one is even shorter: insertList asclist map = union map (Data.Map.fromList asclist) Still I find both of them useful also execution speed seems to be of some concern here. Why generate temporary map just to join it with second in a moment? Isn't it slower? Also why Data.Map.lookup and Data.Map.findWithDefault? Why not lookupWithDefault? Besides, I really like new library :) -- Gracjan

2 2

Ord type on lists
by Lloyd Smith 03 Apr '05

03 Apr '05

Hi everyone, I defined my own list datatype and then tried to declare it as an instance of type class Ord. However when I test it with Nil > Cons 1(Nil) I get an "ERROR - Control stack overflow" I am under the impression that the ord class defines default implementations of (<=), (>),(>=) so that I only have to supply the implementation of (<) shown below. Can some one tell me why this does not work the way I expect it to? My very own list data type > data List a = Nil > | Cons a (List a) > deriving (Show) Derive the equality type for list. > instance (Eq a) => Eq (List a) where > Nil == Nil = True > Nil == Cons y ys = False > Cons x xs == Nil = False > Cons x xs == Cons y ys = (x == y) && (xs == ys) Derive the ordered type for list > instance (Ord a) => Ord (List a) where > Nil < Nil = False > Nil < Cons y ys = True > Cons x xs < Nil = False > Cons x xs < Cons y ys = (x < y) && (xs < ys) -- Lloyd G Smith

3 4

Existential problem
by Niklas Broberg 01 Apr '05

01 Apr '05

I just can't see why the following code will not type check. I have scaled it down as much as possible: ------------------------------------- -- IO with an extra level annotation newtype IO' t a = MkIO' (IO a) -- levels data H data L -- Explicitly recursive continuation type data C t a = forall t2 . C (C t2 a -> IO t a) transition :: Bool -> IO tx () -> IO t () -> IO t () transition b c d = undefined s1 :: C t () -> IO H () s1 (C k) = trans (True) (k (C s1)) -- :: IO t () (s1 (C k)) -- :: IO H () -------------------------------------- The error message is: Inferred type is less polymorphic than expected Quantified type variable `t2' is unified with `H' When checking an existential match that binds k :: C t2 a -> IO t a The pattern(s) have type(s): C t1 () The body has type: IO H () In the definition of `s1': s1 (C k) = trans (True) (k (C s1)) (s1 (C k)) The thing is, I'm perfectly happy with t2 being unified with H for this particular definition of s1, but I want to use it in other cases as well. The code that follows the one above is s2 :: C t () -> IO L () s2 (C k) = trans (True) (k (C s2)) -- :: IO t () (s2 (C k)) -- :: IO L () main = s1 (C s2) where t2 instead gets unified with L for the definition of s2. Could someone tell me why this does not work? I'm using GHC 6.2.2. Thanks, /Niklas

4 5

New user, pardon what may be a dumb question
by Mark Goldman 31 Mar '05

31 Mar '05

I am using ghci to learn Haskell. My question is it possible to assign an object that contains state (for lack of knowing the proper terminology) so a variable or some such from the interactive prompt. More concretely I would like to do something like this non-working code snippet: System.Random> x <- return (mkStdGen 45) System.Random> random x :: (int, StdGen) Thanks

2 1

A few questions on using Cabal
by Niklas Broberg 31 Mar '05

31 Mar '05

I've just started experimenting with the new Cabal system, and I must say it's really sweet. Thanks a lot to all involved! After trying it on some simple tasks I have collected a few questions: * What about 'setup uninstall'? Surely there should be an automatic way of uninstalling packages and executables? * Is there some way to direct the installation of a package to an auxiliary package-conf file, i.e. separate from the 'global' and 'user' package databases? E.g. 'runhaskell Setup.hs register --package-conf=foo.conf' (doesn't work) * Is there some way to bundle several packages into a single installation unit? Similar to how you can specify several executables, or executables and a library package, I would want a way to say that a bundle will install several (possibly interrelated) packages at the same time. * If I specify a library package and an executable in the same cabal bundle, where the executable uses the library, the files that make up the library get compiled twice. Once when setting up the package, and then again when compiling the executable. How come? That's all for now, possibly more to come later. =) /Niklas

2 1