- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Categories (cont.)
by wren ng thornton 12 May '13

12 May '13

On 5/8/13 12:14 PM, Conal Elliott wrote: > Hi Wren, > > Have you taken this "constrained categories" experiment further, > particularly for adding products? As I mentioned in a haskell-cafe note > yesterday, I tried and got a frightening proliferation of constraints when > defining method defaults and utility functions (e.g., left- or > right-associating). I haven't investigated further since my previous emails on the idea. When working with them, though, I did notice that things work out a lot better with separate unary constraints on domains and codomains, as opposed to having a binary constraint that relates domains to codomains. (The latter is, of course, strictly more powerful; which may be the problem.) As another part of that project, however, I've been working on type-level arithmetic, and that also leads to a frightening proliferation of constraints. The problem is that even though we can implement the definitions of addition, comparison, etc, there's no good way to teach the constraint solver facts like: m < S m m <= m+n -- For natural numbers, not integers. m <= n -> exists o. n == m+o m <= n -> n <= o -> m <= o etc The introduction of these facts would introduce nondeterminism into the resolution of constraints--- since the solver would need to decide between using the inductive definitions vs these auxilliary facts. My impression is that the difficulties here are the same for both cases... -- Live well, ~wren

1 0

Stream processing
by Ertugrul Söylemez 12 May '13

12 May '13

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 -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.

3 3

I wish cabal-dev to travel back in time
by Alberto G. Corona 11 May '13

11 May '13

Hi Café: I created just now an issue in cabal-dev: https://github.com/creswick/cabal-dev/issues/101 When compiling old developments, I wish cabal-dev to install and build dependencies that were available at a that time I don't know if there are alternatives to solving this issue. I think that this is very useful and necessary, specially now when library updates are increasingly frequent. Maybe this problem is already solved and I just don´t know (as is often the case, for example when, in a sudden aha moment, I reinvented cabal-install months after the release). That is the reason why I tell you about it here in order to discuss it. motivation: I´m installing now an old soft development. Since many of my dependencies were labeled with -any or with > , neither I neither cabal know which library versions are the right ones. By taking into account a date parameter, cabal-dev can figure out which libraries were the latest and the right ones at that time. -- Alberto.

3 2

Re: [Haskell-cafe] Reinventing a solution to configuration problem
by oleg＠okmij.org 11 May '13

11 May '13

I guess you might like then http://okmij.org/ftp/Haskell/types.html#Prepose which discusses implicit parameters and their drawbacks (see Sec 6.2).

1 0

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 11 May '13

11 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 11 May '13

11 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