- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Thompson's Exercise 9.13
by Daniel Fischer 11 Apr '05

11 Apr '05

Am Sonntag, 10. April 2005 17:33 schrieben Sie: > On 2005/04/10, at 18:18, Daniel Fischer wrote: > >> But this returns [] and doesn't work. I can't get "left" to know that > >> it is working with the rightmost element. It just throws away every > >> element when its right hand side is empty. > >> > >> I found a solution that works for Strings, but I am looking for a more > >> general solution. This exercise may yet again be one of those that is > >> difficult to solve with my current knowledge of Haskell, but I'm > >> asking > >> anyway. > > > > I cannot imagine how you could do it for Strings, but not for general > > lists. > > Mind sending me the code? > > The code is here: > http://wiki.pragprog.com/cgi-bin/wiki.cgi/ThompsonNineAnswersJD Look > for 9.13 towards the bottom of the page. > > It uses chr 0 as an end of string marker, and so this solution only > works for Strings. Unfortunately, Strings may contain '\0': *Init> finit "this doesn't\0quite\0work\0!" "this doesn't\NULquite\NULwor" so it doesn't work in all cases. The idea is nice, though: import Data.Maybe finit = catMaybes . foldr f [Nothing] . map Just where f x ys = case ys of [Nothing] -> [] _ -> x:ys will do fine. > > -- > Kaoru Hosokawa > khosokawa(a)gmail.com Cheers, Daniel

1 2

List containing different types but all implementing the same class
by Bo Herlin 09 Apr '05

09 Apr '05

Hi everyone. Being new to Haskell I wonder how I can make a list contain different types but all implementing the same class, like this: data X = X data Y = Y class Z a where f :: a -> Int instance Z X where f x = 0 instance Z Y where f y = 1 test1 :: Z a => [a] test1 = [X,Y] test2 = map f test1 Is it possible to make this work? /Bo Herlin

3 4

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 06 Apr '05

06 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 06 Apr '05

06 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