Re: [Haskell-cafe] Adding type annotations to an AST?
> How do I add type annotations to interior locations in an abstract > syntax tree? > i.e. the type it [algorithm] infers is the type of the whole > program, I would also like the types of any internal let-rec > definitions so I can label my AST. I had exactly the same problem: type reconstruction and the annotation of all sub-terms with their inferred types. Even if the overall type inference fails, the user can still see what the type checker was able to infer before the error. Here is the solution http://okmij.org/ftp/Computation/FLOLAC/TEvalNR.hs There is a bit of the explanation here: http://okmij.org/ftp/Computation/FLOLAC/lecture.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Double-dispatch
Wow, that's a lot of freedom in the type system. Haskell never fails
to amaze me how it can remove features and increase expressiveness in
one fell sweep.
I also like how the user will get type errors if attempting
intersection between two geometries which do not have intersection
defined. It makes the API really intuitive.
In terms of the extra features, in my case (geometric intersection
tests), MultiParamTypeClasses seem to be the perfect fit. However,
thanks for giving me a much more comprehensive arsenal of type system
hacks!
Regards,
- clark
On Tue, Mar 6, 2012 at 12:28 AM, wren ng thornton wrote:
> On 3/5/12 4:24 PM, Clark Gaebel wrote:
>>
>> Well look at that.
>>
>> Thanks!
>>
>> On Mon, Mar 5, 2012 at 4:07 PM, Felipe Almeida Lessa
>> wrote:
>>>
>>> {-# LANGUAGE MultiParamTypeClasses #-}
>>>
>>> class Intersectable a b where
>>> intersectsWith :: a -> b -> Bool
>
>
> Assuming that intersectsWith is something like unification, equality, or
> similar operations:
>
> Do note that this can lead to needing quadratically many instances, about
> half of which will be redundant if intersectsWith is supposed to be
> symmetric.
>
> Often times we know that the vast majority of these quadratically many
> instances should be vacuous (i.e., always return False), and it'd be nice to
> avoid writing them out. This can be achieved via -XOverlappingInstances
> where you give a default instance:
>
> instance Intersectable a b where intersectsWith _ _ = False
>
> and then override it for more specific choices of a and b. Beware that if
> you want to have other polymorphic instances you may be forced to use
> -XIncoherentInstances, or else resolve the incoherence by filling out the
> lattice of instances.
>
> The other notable complication is if you want your collection of types to
> have more than just a set structure (e.g., if you want some kind of
> subtyping hierarchy). It's doable, but things get complicated quickly.
>
>
> Other than those caveats, have at it! The ability to do this sort of thing
> is part of what makes Haskell great. Few languages have multiple-dispatch
> this powerful.
>
> --
> Live well,
> ~wren
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Higher types in contexts
On 3/5/12 5:13 PM, AntC wrote: I've tried that ListFunc wrapping you suggest: [...] But I can't 'dig out' the H-R function and apply it (not even monomorphically): That's because the suggestion changed it from a universal quantifier to an existential quantifier. data Exists f = forall a. Exists (f a) data Forall f = Forall (forall a. f a) With Exists, we're essentially storing a pair of the actual type 'a' and then the f a itself. We can't just pull out the f a and use it, because we don't know what 'a' is. We can bring it into scope temporarily by case matching on the Exists f, which allows us to use polymorphic functions, but we still don't actually know what it is so we can *only* use polymorphic functions. Conversely, with Forall we're storing some f a value which is in fact polymorphic in 'a'. Here, because it's polymorphic, the caller is free to choose what value of 'a' they would like the f a to use. Indeed, they can choose multiple different values of 'a' and get an f a for each of them. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Double-dispatch
On 3/5/12 4:24 PM, Clark Gaebel wrote:
Well look at that.
Thanks!
On Mon, Mar 5, 2012 at 4:07 PM, Felipe Almeida Lessa
wrote:
{-# LANGUAGE MultiParamTypeClasses #-}
class Intersectable a b where
intersectsWith :: a -> b -> Bool
Assuming that intersectsWith is something like unification, equality, or
similar operations:
Do note that this can lead to needing quadratically many instances,
about half of which will be redundant if intersectsWith is supposed to
be symmetric.
Often times we know that the vast majority of these quadratically many
instances should be vacuous (i.e., always return False), and it'd be
nice to avoid writing them out. This can be achieved via
-XOverlappingInstances where you give a default instance:
instance Intersectable a b where intersectsWith _ _ = False
and then override it for more specific choices of a and b. Beware that
if you want to have other polymorphic instances you may be forced to use
-XIncoherentInstances, or else resolve the incoherence by filling out
the lattice of instances.
The other notable complication is if you want your collection of types
to have more than just a set structure (e.g., if you want some kind of
subtyping hierarchy). It's doable, but things get complicated quickly.
Other than those caveats, have at it! The ability to do this sort of
thing is part of what makes Haskell great. Few languages have
multiple-dispatch this powerful.
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Higher types in contexts
>I don't know what you want to do, but you may wrap the (forall a. [a] ->
[a]) in an existential type:
>data ListFunc = forall a. ListFunc ([a] -> [a])
>class Has r Rev ListFunc => HRClass r where
> setHRClass :: ListFunc -> r -> r
Thanks Henning,
What we're wanting to do is set the Higher-ranked function into a record
type, then get it and apply it polymorphically. SPJ's example is:
data HR = HR { rev :: forall a. [a] -> [a] } -- where rev is the
label for the H-R function
f :: HR -> ([Bool], [Char])
f r = (r.rev [True], r.rev "hello") -- where r.rev
is new syntax to get the func from HR
I've tried that ListFunc wrapping you suggest:
data HR = HR { rev :: ListFunc }
rHR1 = HR{ rev = ListFunc reverse } -- put the `reverse`
function into the record type
--
the setHRClass method would do this
But I can't 'dig out' the H-R function and apply it (not even
monomorphically):
case (rev rHR1) of { (ListFunc fn) -> fn "hello" }
==> Couldn't match type `a' with `Char'
`a' is a rigid type variable bound by
a pattern with constructor
ListFunc :: forall a. ([a] -> [a]) -> ListFunc,
in a case alternative
at :0:25
Expected type: [a]
Actual type: [Char]
SPJ's approach (without a wrapper, but with some fancy instance constraints)
can 'dig out' the function and apply it polymorphically, but he can't get
the function into the record without using an explicit data constructor.
What am I doing wrong?
AntC
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Re-Haskell-Higher-types-in-contexts-tp5537428p5539147.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Double-dispatch
Well look at that.
Thanks!
On Mon, Mar 5, 2012 at 4:07 PM, Felipe Almeida Lessa
wrote:
> {-# LANGUAGE MultiParamTypeClasses #-}
>
> class Intersectable a b where
> intersectsWith :: a -> b -> Bool
>
> --
> Felipe.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Double-dispatch
{-# LANGUAGE MultiParamTypeClasses #-}
class Intersectable a b where
intersectsWith :: a -> b -> Bool
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Double-dispatch
Is there any way in Haskell to have the correct function selected based on the types of two different types? For example, let's say I'm writing intersection tests: aABBandAABB :: AABB -> AABB -> Bool oBBandOBB :: OBB -> OBB -> Bool oBBandPoint :: OBB -> Point -> Bool Is there some way (such as with Type Families) that I can write some sort of generic method for this: intersects :: Intersectable -> Intersectable -> Bool which automatically selects the right function to call based on the types of the two intersectables? Regards, - clark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit Sink fork
Sorry for the repeat postings. My machine freaked out > From: mich...@snoyman.com > Date: Mon, 5 Mar 2012 16:56:11 +0200 > Subject: Re: [Haskell-cafe] Conduit Sink fork > To: the...@hotmail.com > CC: haskell-cafe@haskell.org > > On Mon, Mar 5, 2012 at 1:54 AM, t helfferich wrote: > > Hi! > > So, it turns out I have a need for a sink that forks input into two other > > sinks using the Conduit package. Here is what I came up > > with: https://gist.github.com/1975383 > > > > Is this the right way to write it? Also, what left over value(s) should I > > return in the Done constructor? > > > > I appreciate any help you can give me. > > > > Thanks so much, > > Grant > > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > It looks like the right approach to me. What to do with the leftover > values is a really good question, and I don't think there's really an > obvious answer. I can think of a few approaches: > > * What you've done: never return leftover values. > * Always return the ll (or rr). > * Return whichever leftover value is Just, or if both are Just, > arbitrarily choosing one of them > > Similarly, you could take different approaches to what to do when > processing terminates early: > > * What you've done: continue pushing data until both Sinks return Done > * Terminate whenever the left (or right) Sink returns Done > * Terminate when *either* returns Done > > Again, there's no right answer here, they all seem like valid approaches. > > Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit Sink fork
Thanks. That makes sense.Grant > From: mich...@snoyman.com > Date: Mon, 5 Mar 2012 16:56:11 +0200 > Subject: Re: [Haskell-cafe] Conduit Sink fork > To: the...@hotmail.com > CC: haskell-cafe@haskell.org > > On Mon, Mar 5, 2012 at 1:54 AM, t helfferich wrote: > > Hi! > > So, it turns out I have a need for a sink that forks input into two other > > sinks using the Conduit package. Here is what I came up > > with: https://gist.github.com/1975383 > > > > Is this the right way to write it? Also, what left over value(s) should I > > return in the Done constructor? > > > > I appreciate any help you can give me. > > > > Thanks so much, > > Grant > > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > It looks like the right approach to me. What to do with the leftover > values is a really good question, and I don't think there's really an > obvious answer. I can think of a few approaches: > > * What you've done: never return leftover values. > * Always return the ll (or rr). > * Return whichever leftover value is Just, or if both are Just, > arbitrarily choosing one of them > > Similarly, you could take different approaches to what to do when > processing terminates early: > > * What you've done: continue pushing data until both Sinks return Done > * Terminate whenever the left (or right) Sink returns Done > * Terminate when *either* returns Done > > Again, there's no right answer here, they all seem like valid approaches. > > Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit Sink fork
Thanks. That makes sense.Grant > From: mich...@snoyman.com > Date: Mon, 5 Mar 2012 16:56:11 +0200 > Subject: Re: [Haskell-cafe] Conduit Sink fork > To: the...@hotmail.com > CC: haskell-cafe@haskell.org > > On Mon, Mar 5, 2012 at 1:54 AM, t helfferich wrote: > > Hi! > > So, it turns out I have a need for a sink that forks input into two other > > sinks using the Conduit package. Here is what I came up > > with: https://gist.github.com/1975383 > > > > Is this the right way to write it? Also, what left over value(s) should I > > return in the Done constructor? > > > > I appreciate any help you can give me. > > > > Thanks so much, > > Grant > > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > It looks like the right approach to me. What to do with the leftover > values is a really good question, and I don't think there's really an > obvious answer. I can think of a few approaches: > > * What you've done: never return leftover values. > * Always return the ll (or rr). > * Return whichever leftover value is Just, or if both are Just, > arbitrarily choosing one of them > > Similarly, you could take different approaches to what to do when > processing terminates early: > > * What you've done: continue pushing data until both Sinks return Done > * Terminate whenever the left (or right) Sink returns Done > * Terminate when *either* returns Done > > Again, there's no right answer here, they all seem like valid approaches. > > Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit Sink fork
Thanks. That makes sense.Grant > From: mich...@snoyman.com > Date: Mon, 5 Mar 2012 16:56:11 +0200 > Subject: Re: [Haskell-cafe] Conduit Sink fork > To: the...@hotmail.com > CC: haskell-cafe@haskell.org > > On Mon, Mar 5, 2012 at 1:54 AM, t helfferich wrote: > > Hi! > > So, it turns out I have a need for a sink that forks input into two other > > sinks using the Conduit package. Here is what I came up > > with: https://gist.github.com/1975383 > > > > Is this the right way to write it? Also, what left over value(s) should I > > return in the Done constructor? > > > > I appreciate any help you can give me. > > > > Thanks so much, > > Grant > > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > It looks like the right approach to me. What to do with the leftover > values is a really good question, and I don't think there's really an > obvious answer. I can think of a few approaches: > > * What you've done: never return leftover values. > * Always return the ll (or rr). > * Return whichever leftover value is Just, or if both are Just, > arbitrarily choosing one of them > > Similarly, you could take different approaches to what to do when > processing terminates early: > > * What you've done: continue pushing data until both Sinks return Done > * Terminate whenever the left (or right) Sink returns Done > * Terminate when *either* returns Done > > Again, there's no right answer here, they all seem like valid approaches. > > Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit Sink fork
Thanks. That makes sense.Grant > From: mich...@snoyman.com > Date: Mon, 5 Mar 2012 16:56:11 +0200 > Subject: Re: [Haskell-cafe] Conduit Sink fork > To: the...@hotmail.com > CC: haskell-cafe@haskell.org > > On Mon, Mar 5, 2012 at 1:54 AM, t helfferich wrote: > > Hi! > > So, it turns out I have a need for a sink that forks input into two other > > sinks using the Conduit package. Here is what I came up > > with: https://gist.github.com/1975383 > > > > Is this the right way to write it? Also, what left over value(s) should I > > return in the Done constructor? > > > > I appreciate any help you can give me. > > > > Thanks so much, > > Grant > > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > It looks like the right approach to me. What to do with the leftover > values is a really good question, and I don't think there's really an > obvious answer. I can think of a few approaches: > > * What you've done: never return leftover values. > * Always return the ll (or rr). > * Return whichever leftover value is Just, or if both are Just, > arbitrarily choosing one of them > > Similarly, you could take different approaches to what to do when > processing terminates early: > > * What you've done: continue pushing data until both Sinks return Done > * Terminate whenever the left (or right) Sink returns Done > * Terminate when *either* returns Done > > Again, there's no right answer here, they all seem like valid approaches. > > Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reasons for Super-Linear Speedup
On 03/05/2012 04:58 PM, burak ekici wrote: Dear List; I have parallelized RSA decryption and encryption schemes by using second generation strategies of Haskell p.l. In that case, what I got in the sense of speed up was nearly 10 times of better performances (on a quad-core CPU with 8M cache) in the parallel evaluation of 125K long plain text with 180-bit of an encryption key, in comparison with the serial evaluation, abnormally. The explanation for this kind of thing is usually that all the working data suddenly fits within the per-CPU L2 cache when split up. Regards, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Reasons for Super-Linear Speedup
Dear List; I have parallelized RSA decryption and encryption schemes by using second generation strategies of Haskell p.l. In that case, what I got in the sense of speed up was nearly 10 times of better performances (on a quad-core CPU with 8M cache) in the parallel evaluation of 125K long plain text with 180-bit of an encryption key, in comparison with the serial evaluation, abnormally. All my thoughts are in the direction of getting wrong serial-time performances. My question here is that is there any difference between serial and parallel evaluation of any arbitrary computation in terms of "cache usage methodologies" in Haskell compiler design. If no; what could be other possible reasons? I would be much more than appreciated, if somebody brings an acceptable pinpoint for the issue. Many thanks in advance. Kind regards Burak. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit Sink fork
On Mon, Mar 5, 2012 at 1:54 AM, t helfferich wrote: > Hi! > So, it turns out I have a need for a sink that forks input into two other > sinks using the Conduit package. Here is what I came up > with: https://gist.github.com/1975383 > > Is this the right way to write it? Also, what left over value(s) should I > return in the Done constructor? > > I appreciate any help you can give me. > > Thanks so much, > Grant > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > It looks like the right approach to me. What to do with the leftover values is a really good question, and I don't think there's really an obvious answer. I can think of a few approaches: * What you've done: never return leftover values. * Always return the ll (or rr). * Return whichever leftover value is Just, or if both are Just, arbitrarily choosing one of them Similarly, you could take different approaches to what to do when processing terminates early: * What you've done: continue pushing data until both Sinks return Done * Terminate whenever the left (or right) Sink returns Done * Terminate when *either* returns Done Again, there's no right answer here, they all seem like valid approaches. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about concurrency, threads and GC
Hello. I've also written simple chat server based on conduits and stm channels https://github.com/qnikst/chat-server/blob/master/src/Main.hs it has quite similar aproach and maybe this solution can be used together to have better results. -- Alexander Vershilov Sat, Mar 03, 2012 at 02:05:17AM -0500, Joey Adams wrote > On Fri, Mar 2, 2012 at 7:34 PM, Joey Adams wrote: > > I'll try to put together a simple chat server example, like the one I > > wrote for stm-channelize. > > Here it is: > > https://github.com/joeyadams/haskell-chat-server-example > > See, in particular, the serveLoop function. When a message is > received from the client, it is written to the send channel of every > other client. When a message is written on the client's own send > channel, it is transmitted to the client. The primary thread for the > client waits until one of the worker threads signals completion, then > kills both of the worker threads. > > I hope this example gives you some ideas. > > -Joey signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Adding type annotations to an AST?
Partially answering my own question - it seems like I want "type directed translation" as per section 8 of "Practical Type Inference for Arbitrary Ranked Types". Does anyone know of a presentation with a simpler type language? Thanks again Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Higher types in contexts
moved to haskell-cafe On Mon, 5 Mar 2012, Barney Hilken wrote: Is there any deep reason why I can't write a polymorphic type in a context? I think the record update problem can be (sort of) solved if you could write: class Has r Rev (forall a. [a] -> [a]) => HRClass r where setHRClass :: (forall a.[a] -> [a]) -> r -> r but polymorphic types are not allowed in contexts. Is this one of the problems SPJ considers "Hard" or is it a feasible extension? I don't know what you want to do, but you may wrap the (forall a. [a] -> [a]) in an existential type: data ListFunc = forall a. ListFunc ([a] -> [a]) class Has r Rev ListFunc => HRClass r where setHRClass :: ListFunc -> r -> r ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [haskell-cafe] Question about 64bit target on Windows platform
On Mon, Mar 5, 2012 at 2:54 PM, Simon Marlow wrote: > There is a possibility that the IHG might fund this during the next cycle, > which would mean that it would be in 7.6.1. > > Cheers, >Simon > > That is very good to hear!!! Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [haskell-cafe] Question about 64bit target on Windows platform
There is a possibility that the IHG might fund this during the next cycle, which would mean that it would be in 7.6.1. Cheers, Simon On 05/03/2012 07:35, Jason Dagit wrote: I don't know if timeline has been established, but my understanding is that there is a need for this and that the right people are aware of it and looking into it. The GHC trac has a ticket for this: http://hackage.haskell.org/trac/ghc/ticket/1884 On Sun, Mar 4, 2012 at 9:59 PM, C K Kashyap wrote: Hi All, Can someone please let me know if there is a 64bit target on Windows on the horizon for GHC? I am trying to push for changing the current implementation in my organization in C++ to Haskell - Our primary targets are Windows and Mac. Not being able to generate 64bit DLL's on Windows would be a big bottleneck. Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [haskell-cafe] Question about 64bit target on Windows platform
Thank you Jason. On Mon, Mar 5, 2012 at 1:05 PM, Jason Dagit wrote: > I don't know if timeline has been established, but my understanding is > that there is a need for this and that the right people are aware of > it and looking into it. > > The GHC trac has a ticket for this: > http://hackage.haskell.org/trac/ghc/ticket/1884 > > On Sun, Mar 4, 2012 at 9:59 PM, C K Kashyap wrote: > > Hi All, > > Can someone please let me know if there is a 64bit target on Windows on > the > > horizon for GHC? > > I am trying to push for changing the current implementation in my > > organization in C++ to Haskell - Our primary targets are Windows and Mac. > > Not being able to generate 64bit DLL's on Windows would be a big > bottleneck. > > Regards, > > Kashyap > > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
