- Haskell-Cafe - Haskell.org

Typeclass with an `or' restriction.
by oleg＠okmij.org 11 May '13

11 May '13

Mateusz Kowalczyk wrote: > Is there a way however to do something along the lines of: > > class Eq a => Foo a where bar :: a -> a -> Bool bar = (==) > > > > class Num a => Foo a where bar :: a -> a -> Bool bar _ _ = False > This would allow us to make an instance of Num be an instance of Foo > or an instance of Eq to be an instance of Foo. GADTs are a particular good way to constraint disjunction, if you can live with the closed universe. (In the following example I took a liberty to replace Int with Ord, to make the example crispier.) > {-# LANGUAGE GADTs #-} > > data OrdEq a where > Ord :: Ord a => OrdEq a -- representation of Ord dict > Eq :: Eq a => OrdEq a -- representation of Eq dict > > bar :: OrdEq a -> a -> a -> Bool > bar Ord x y = x > y > bar Eq x y = x == y The function bar has almost the desired signature, only (OrdEq a ->) has the ordinary arrow rather than the double arrow. We can fix that: > class Dict a where > repr :: OrdEq a > > -- We state that for Int, we prefer Ord > instance Dict Int where > repr = Ord > > bar' :: Dict a => a -> a -> Bool > bar' = bar repr > > test = bar' (1::Int) 2 I can see the utility of this: something like C++ STL iterators and algorithms? An algorithm could test if a bidirectional iterator is available, or it has to do, less efficiently, with unidirectional. Of course we can use ordinary type classes, at the cost of the significant repetition. In the OrdEq example above, there are only two choices of the algorithm for Bar: either the type supports Ord, or the type supports Eq. So the choice depends on wide sets of types rather than on types themselves.

1 0

Re: [Haskell-cafe] Stream Processing
by Gabriel Gonzalez 11 May '13

11 May '13

As far as I can tell, the only thing on that list not solved currently by `pipes` is leftovers, but I will be releasing that very soon. > Hello everybody, > > I'm trying to formulate the stream processing problem, which doesn't > seem to be solved fully by the currently existing patterns. I'm > experimenting with a new idea, but I want to make sure that I don't miss > any defining features of the problem, so here is my list. A stream > processing abstraction should: > > * have a categorically proven design (solved by iteratees, pipes), > > * be composable (solved by all of them), > > * be reasonably easy to understand and work with (solved by conduit, > pipes), > > * support leftovers (solved by conduit and to some degree by > iteratees), > > * be reliable in the presence of async exceptions (solved by conduit, > pipes-safe), > > * hold on to resources only as long as necessary (solved by conduit > and to some degree by pipes-safe), > > * ideally also allow upstream communication (solved by pipes and to > some degree by conduit). > > * be fast (solved by all of them). > > Anything else you would put in that list? > > > Greets, > Ertugrul >

1 0

A use case for *real* existential types
by Leon Smith 10 May '13

10 May '13

I've been working on a new Haskell interface to the linux kernel's inotify system, which allows applications to subscribe to and be notified of filesystem events. An application first issues a system call that returns a file descriptor that notification events can be read from, and then issues further system calls to watch particular paths for events. These return a watch descriptor (which is just an integer) that can be used to unsubscribe from those events. Now, of course an application can open multiple inotify descriptors, and when removing watch descriptors, you want to remove it from the same inotify descriptor that contains it; otherwise you run the risk of deleting a completely different watch descriptor. So the natural question here is if we can employ the type system to enforce this correspondence. Phantom types immediately come to mind, as this problem is almost the same as ensuring that STRefs are only ever used in a single ST computation. The twist is that the inotify interface has nothing analogous to runST, which does the "heavy lifting" of the type magic behind the ST monad. This twist is very simple to deal with if you have real existential types, with the relevant part of the interface looking approximately like init :: exists a. IO (Inotify a) addWatch :: Inotify a -> FilePath -> IO (Watch a) rmWatch :: Inotify a -> Watch a -> IO () UHC supports this just fine, as demonstrated by a mockup attached to this email. However a solution for GHC is not obvious to me.

4 8

Where is haskell-platform?
by Clark Gaebel 10 May '13

10 May '13

I'm looking for the version of haskell platform that was "supposed" to be released May 6. It seems like it isn't out yet. What's preventing this from happening, and is there anything I can do to help? Regards, - Clark

1 0

Constrained Category, Arrow, ArrowChoice, etc?
by Conal Elliott 10 May '13

10 May '13

I'm using a collection of classes similar to Category, Arrow, ArrowChoice, etc (though without arr and with methods like fst, snd, dup, etc). I think I need some associated constraints (via ConstraintKinds), so I've tried adding them. However, I'm getting terribly complex multiplication of these constraints in the signatures of method defaults and utility functions, and I don't know how to tame them. Has anyone tried adding associated constraints to Category etc? Thanks, -- Conal

2 4

Typeclass with an ‘or’ restriction.
by Mateusz Kowalczyk 10 May '13

10 May '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, We can currently do something like > class (Num a, Eq a) => Foo a where bar :: a -> a -> Bool bar = > (==) This means that our `a' has to be an instance of Num and Eq. Apologies for a bit of an artificial example. Is there a way however to do something along the lines of: > class Eq a => Foo a where bar :: a -> a -> Bool bar = (==) > > class Num a => Foo a where bar :: a -> a -> Bool bar _ _ = False This would allow us to make an instance of Num be an instance of Foo or an instance of Eq to be an instance of Foo. The compiler currently complains about multiple declarations. Is there currently a way to achieve this? The main issue I can see with this is that given an instance of both, Num and Eq, it wouldn't be possible to pick the correct default implementation. Purely a theoretical question. - -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRjP0hAAoJEM1mucMq2pqX30wP/0d0TQHs4S3G5TBw+T1baI6n g/5k/YlPmSgS3FaO8JMQsb2uqL8dGPZGUN7d2ohwcigtXS88KWH4u4rTjrs1+p8o ktS+vIE4kEEedTAX6wmP2Zn+rvK2zFGboCafaX/a/IxT5CbwYZ97RrWCjzz1jlPs S/VlhNHcTQ7Cf/0pa0xJ1kbao+vBHiWtWjxcdzCT/6zS86+jm9vz8qrYT3TWUd3y AJXPBjRuXeyz+RDv18yrth7hMlAvaeoWzmC4gbGFHC68/Oq2l8kz+4dt6ApN+mIy l73wNjrU185YoZ2dkuKTIph8/BadgkD+9ktkgZZ/NlqxElc596BdbOcMfVk4rz4A 0nWqaLa4QctIthghJ1UNfKS8lQzkVVRT6e03LYdgPkqJm1HQxkjHL/WieV2NEoRf 1K9S4SVW8Aq/ML/Gmx782Z3jMECfnYWntf9gSOwFASB64tVej1iUxb7UsfxJAL1t ysf9MjcbZsHe3M/JAq4f8HtHoZoiIG/TTjD0yo74owssJDfOTDqmYMriyelcnUf6 hDCPZyUqLPMTNVx07T+gwfXJoE1HK20hzVe2o1dPBZ8Kb2KJbNg0+sUSB3/v6O8e EJ6w7aQ3OnZUACd1i2uLZiphMF8d8va4T8eTFUyROODHvaPv6netzr8gPcIXhpVO 5OwyMfO54cinZYen7+HR =iAYY -----END PGP SIGNATURE-----

2 1

Reinventing a solution to configuration problem
by Krzysztof Skrzętnicki 10 May '13

10 May '13

Hello Cafe, I came up with (actually reinvented [1]) a solution to configuration problem. For example configuration: data Config = Config { port :: Int, verbosity :: Int, logfile :: FilePath } deriving Show the basic idea is to use implicit parameters: runServer :: (?config :: Config) => IO () The problem is that it is tiresome to decorate all functions in this way. It is also non composable. For example if we switch to using two separate configuration entities like this: data LogConfig = LogConfig { verbosity :: Int, logfile :: FilePath } data NetConfig = NetConfig { port :: Int } we suddenly have to fix types all over the place. Yuck. The extended idea here (compared to [2]) is to use type synonym with all required parameters. This is simple (but requires at least Rank2Types): type ConfIO a = (?config :: Config) => IO a All the functions requiring config will now be simply in ConfIO monad which is really IO with a bonus. A great feature of this solution is that we don't need to use liftIO anywhere. The core *problem* with this approach is that at least current version of GHC fails to propagate implicit parameters the way it propagate typeclass requirements. For example I would like the following function to have (inferred) type -- printConfig :: (?config :: Config) => IO () printConfig = print (?config :: Config) Instead GHC will complain about unbound implicit parameter. Similar problem from GHCi session: Prelude> let f = print (?conf :: Int) <interactive>:11:16: Unbound implicit parameter (?conf::Int) arising from a use of implicit parameter `?conf' In the first argument of `print', namely `(?conf :: Int)' In the expression: print (?conf :: Int) In an equation for `f': f = print (?conf :: Int) For reason I don't fully understand this is fixed by disabling monomorphic restriction. The documentation mentions the problem but in a different context: http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensio… *TL;DR*: A nice solution to configuration problem is to use implicit parameters and type synonym for IO monad extended with implicit configuration parameters. It requires Rank2Types for defining the synonym and NoMonomorphismRestriction for lightweight use. Best regards, Krzysztof Skrzętnicki [1] I only realised this after starting the writing of this email. The implicit parameters solution is given at least in [2]. Somehow I didn't came across it before. [2] "Global Variables in Haskell (2004)"<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.23.145&rep=rep1&ty…> by John Hughes

1 0

Flip around type parameters?
by Christopher Howard 10 May '13

10 May '13

Hi. Does Haskell allow you to flip around type parameters somehow? I was playing around with toy code (still learning the fundamentals) and I came up with a class like this: code: -------- class Rotatable2D a where rotate :: (Num b) => (a b) -> b -> (a b) -------- It was easy to make an instance of a generic single-parameter type: code: -------- data Angle a = Angle a deriving (Show) instance Rotatable2D Angle where rotate (Angle a) b = Angle (a + b) -------- But let's say I have something a little more complicated: code: -------- data CircAppr a b = CircAppr a a b -- radius, rotation angle, number of points -------- I think I need something like so: -------- instance Rotatable2D (\x -> CircAppr x a) where rotate (CircAppr a b c) d = CircAppr a (b + d) c -------- But I tried that and it isn't valid syntax. -- frigidcode.com

2 1

Fwd: Error compiling transformers-base-0.4.1 (debian 64 bits, ghc-7.4.2)
by jean-christophe mincke 09 May '13

09 May '13

Thank you Sjoerd, Unfortunately this does not work. I think the problem is linked to the evaluation of the condition (in Base.hs) #if !MIN_VERSION_base(4,4,0) && HS_TRANSFORMERS_BASE__ORPHANS Just as a test, I modified the file and added the following lines A. negation of min_version #if *!*MIN_VERSION_base(4,4,0) rgfyfgruyfgreuy -- making sure the compilation fails #endif B #if MIN_VERSION_base(4,4,0) rgfyfgruyfgreuy -- making sure the compilation fails #endif In both case the compilations failed (cabal clean, configure, build). That is, it seems that the #if always evaluate to true... I am surely missing something here... Regards J-C On Thu, May 9, 2013 at 4:13 PM, Sjoerd Visscher <sjoerd(a)w3future.com> wrote: > There's a flag to turn it off, does that work? Try cabal install > transformers-base -f-OrphanInstances > > Sjoerd > > On May 9, 2013, at 2:47 PM, jean-christophe mincke < > jeanchristophe.mincke(a)gmail.com> wrote: > > Hello Café > > I am running into problems when installing transformers-base-0.4.1. > > Has anyone an idea about what is going on? > > REM : this is a "brand new" debian install, I have just install ghc, cabal > install cabal-install etc. > > Thank you > > very much > > J-C > > cabal install transformers-base > Resolving dependencies... > Downloading transformers-base-0.4.1... > Configuring transformers-base-0.4.1... > Preprocessing library transformers-base-0.4.1... > Building transformers-base-0.4.1... > [1 of 1] Compiling Control.Monad.Base ( src/Control/Monad/Base.hs, > dist/build/Control/Monad/Base.o ) > > src/Control/Monad/Base.hs:63:10: > Duplicate instance declarations: > instance Applicative (L.ST <http://l.st/> s) > -- Defined at src/Control/Monad/Base.hs:63:10 > instance Applicative (L.ST <http://l.st/> s) -- Defined in > `Control.Applicative' > > src/Control/Monad/Base.hs:67:10: > Duplicate instance declarations: > instance Applicative (S.ST <http://s.st/> s) > -- Defined at src/Control/Monad/Base.hs:67:10 > instance Applicative (S.ST <http://s.st/> s) -- Defined in > `Control.Applicative' > cabal: Error: some packages failed to install: > transformers-base-0.4.1 failed during the building phase. The exception > was: > ExitFailure 1 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > >

1 1

Accessing resource files in tests
by Graham Berks 09 May '13

09 May '13

Hi, whats the recommended way to access a resource file for a test within cabal. I have a text file containing data that I use in a test and want to be able to access it in a root path independent manner. Thanks

2 1