Re: [Haskell-cafe] [Haskell] Defining Cg, HLSL style vectors in Haskell
Hi Slavomir, On 11/28/06, Slavomir Kaslev [EMAIL PROTECTED] wrote: instance Num Float3 where . signum a | a == Float3 0 0 0 = 0 | otherwise = 1 signum has a natural generalization for vectors. signum v = vector with the same direction as v but with |v| = 1 where |v| is the absolute length of v. The problematic function in Num is abs. Ideally abs should be defined as: abs v = |v| but its type is Float3 - Float while the Num class requires Float3 - Float3. Cheers, Krasimir ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] ANNOUNCE: Visual Haskell prerelease 0.2
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Waldmann sounds great - but can I use this without buying Visual Studio first, i. e. does it work with some free beta version or similar? and, does it then work under wine :-) seriously, how hard would it be to adapt VH to Eclipse? the interfaces (for syntax highlighting, typechecking etc.) should be similar - in theory. Johannes, Are you aware that there is a Haskell plugin for eclipse? http://eclipsefp.sourceforge.net/ It's probably not as sophisticated as VH (I haven't tried VH, so cannot comment with authority), but you get syntax highlighting/colouring, compile-on-save, and compile errors are highlighted in the source editor. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] generating javascript
Hi Jeff, It all depends how you want to write your code. The two options are full Haskell (Yhc) or combinators (HSPClientSide). Thanks Neil On 11/29/06, jeff p [EMAIL PROTECTED] wrote: Hello, There's a Google SoC-project made by a friend of mine for JavaScript support in Haskell Server Pages: http://csmisc14.cs.chalmers.se/~bjornson/soc/ It's a combinator library, but i'm not sure it's what you really need though. :) This seems to contain just what I was looking for. Although I'm not using HSP, it looks like the HSPClientside library can be used (in conjunction with Text.XHtml) to generate webpages with embedded scripts. thanks, Jeff ___ 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] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
| In many useful cases, such as the getLine example, the Y action will have its
| own atomic {} block. In which case the semantics of when it is allowed to
| re-attempt X are what is important. If you require (Y) to complete before
| re-attempting (X) then you get an infinite regression where every (atomic
block)
| fails with (retryWith (next atomic block)), and nothing is ever re-attempted.
| This is why retryWith Y meaning rollback X and do Y atomic X is the
wrong
| implementation.
I don't agree. I think it's quite reasonable. Not many atomic blocks will
finish with retryWith. Of course there is a possibility of an infinite loop,
but we already have that: f x = f x. Of course, Y can always choose to do a
forkIO, but it shouldn't hav to.
For me the only difficulty is the implementation. We'd like to block X on the
TVars it read (as usual), *unless* executing Y wrote to any of them. That
requires a bit more cleverness in the commit code, but not a great deal I think.
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: help with threadDelay
On 29/11/06, Ian Lynagh [EMAIL PROTECTED] wrote: On Wed, Nov 22, 2006 at 03:37:05PM +, Neil Davies wrote: Ian/Simon(s) Thanks - looking forward to the fix. I've now pushed it to the HEAD. Thanks - I'll pull it down and give it a try. It will help with the real time enviroment that I've got. Lazy evaluation and GHC's garbage collector will probably cause headaches if you want true real time stuff. So the wisdom goes, but I decided to try it and it works really nicely. Yes, the GC can introduce additional jitter, but I can arrange for GC's to be performed at times more convinient and not on the time critical path. I'm reliably able to get sub-millisecond jitter in the wakeup times - which is fine for the application. Laziness is fine - It'll help later when I can arrange evaluation outside the time critical path. Yea, I'd love a non-locking, incremental GC that returned within a fixed (configurable) time - but until that time Follow on query: Is there a way of seeing the value of this interval from within the Haskell program? Helps in the calibration loop. I don't follow - what interval do you want to know? You can't find out how long threadDelay took, but the lower bound (in a correct implementation) is what you ask for and the upper bound is what you get by measuring it, as you did in your original message. I was trying to find out (in the running haskell) the value supplied by (for example) -V RTS flag. In order to get low jitter you have to deliberately wake up early and spin - hey what are all these extra cores for! - knowing the quantisation of the RTS is useful in calibration loop for how much to wake up early. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Defining Cg, HLSL style vectors in Haskell
On Tue, 28 Nov 2006, Brian Hulley wrote: While it may be tempting to want to use symbolic operators like + and -, these quickly become very confusing when more distinctions need to be made (eg between cross product, dot product, and scaling, or between transforming a position versus transforming a direction) so I'd argue that for readability descriptive names are better than symbols: class Num a = Vector v a where plus :: v a - v a - v a minus :: v a - v a - v a cross :: v a - v a - v a dot :: v a - v a - a scale :: a - v a - v a magSquared :: v a - a I'm currently even thinking about an alternative of the multi-parameter class Vector that is Haskell 98. The problem with the multi-parameter type class is, that you cannot define instances where 'a' is a complex number type, say Num a = Vector [Complex a] (Complex a) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [solved] Re: [Haskell-cafe] c2hs and cabal?
On Wed, Nov 29, 2006 at 03:38:24 +, Duncan Coutts wrote:
On Tue, 2006-11-28 at 17:24 +, Magnus Therning wrote:
On Tue, Nov 28, 2006 at 12:00:50 +, Magnus Therning wrote:
[..]
Can't really see anything obviously bogus about the following:
% cat Foo.chs
module Foo where
#include foo.h
fooOne i = {# call foo1 #} i
I solved my problem, but thought I'd send a mail to the list for anyone
who's struggling as much as me (if that's even possible).
The problem was that GHC requires a commandline argument telling it to
deal with FFI. Including the following in Foo.chs resulted in
successful compilation:
{-# OPTIONS_GHC -fffi #-}
Or the simpler way is to include in your .cabal file:
extensions: ForeignFunctionInterface
That then applies to every module in the lib and has the advantage of
being portable between compilers.
Ah, good point.
Now, where could I have turned to find this out myself? I can't find it
in the Cabal User's Guide[1].
/M
[1]: http://www.haskell.org/cabal/release/latest/doc/users-guide/
--
Magnus Therning (OpenPGP: 0xAB4DFBA4)
[EMAIL PROTECTED] Jabber: [EMAIL PROTECTED]
http://therning.org/magnus
Software is not manufactured, it is something you write and publish.
Keep Europe free from software patents, we do not want censorship
by patent law on written works.
I have steadily endeavored to keep my mind free, so as to give up any
hypothesis, however much beloved -- and I cannot resist forming one
on every subject -- as soon as facts are shown to be opposed to it.
-- Charles Darwin (1809-1882)
pgpZPlH4BCEZ5.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haddock infix questions
Hello Nicolas, Wednesday, November 29, 2006, 7:36:59 AM, you wrote: 1) What ended up happening with David Waern's SoC project? I tried the darcs repo at http://darcs.haskell.org/SoC/haddock.ghc/, but got some now it's integrated in ghc 6.7 (HEAD) version. unfortunately, this years SoC projects don't had chances to be included in ghc 6.6. it was release-candidated in august or september and it will be bad to include new functionality just before RCing ghc -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [solved] Re: [Haskell-cafe] c2hs and cabal?
On Wed, 2006-11-29 at 11:26 +, Magnus Therning wrote: Or the simpler way is to include in your .cabal file: extensions: ForeignFunctionInterface That then applies to every module in the lib and has the advantage of being portable between compilers. Ah, good point. Now, where could I have turned to find this out myself? I can't find it in the Cabal User's Guide[1]. /M [1]: http://www.haskell.org/cabal/release/latest/doc/users-guide/ http://www.haskell.org/cabal/release/latest/doc/users-guide/x30.html#buildinfo Section 2.1.4, though I do notice that the link to the full list of extensions is broken. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Compatibility between Data.ByteString.Base and Data.ByteString.Lazy
Hi, Firstly my apologies if this is an outrageously newbie question. I am trying to write a binary protocol parser using Data.ByteString. I have created a module ByteParser containing my parsing utilities, which imports ByteString as: import qualified Data.ByteString as B In my Main module, where all the IO happens, I want to use lazy ByteStrings so I ask for the following imports: import ByteParser import qualified Data.ByteString.Lazy as L The problem is that when I try to call a function in ByteParser with an L.ByteString, the compiler complains that: Couldn't match expected type `Data.ByteString.Base.ByteString' against inferred type `L.ByteString' Does this mean that the lazy version of ByteString is a completely separate, incompatible type from the base version? Obviously I can work around this problem by making ByteParser import Data.ByteString.Lazy instead of Data.ByteString, but then ByteParser would not be able to work with strict ByteStrings. Ideally I would like ByteParser to be agnostic about the use of lazy versus strict ByteStrings. Is this a sensible and/or possible thing to do? Many thanks, Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compatibility between Data.ByteString.Base and Data.ByteString.Lazy
neil: Hi, Firstly my apologies if this is an outrageously newbie question. I am trying to write a binary protocol parser using Data.ByteString. I have created a module ByteParser containing my parsing utilities, which imports ByteString as: import qualified Data.ByteString as B In my Main module, where all the IO happens, I want to use lazy ByteStrings so I ask for the following imports: import ByteParser import qualified Data.ByteString.Lazy as L The problem is that when I try to call a function in ByteParser with an L.ByteString, the compiler complains that: Couldn't match expected type `Data.ByteString.Base.ByteString' against inferred type `L.ByteString' Does this mean that the lazy version of ByteString is a completely separate, incompatible type from the base version? Obviously I can work Yes, they're completely different. One is a strict, unboxed array of bytes. The other is a lazy list of cache-sized array chunks. You can convert between the two. But usually its best to pick one and stick to it. around this problem by making ByteParser import Data.ByteString.Lazy instead of Data.ByteString, but then ByteParser would not be able to work with strict ByteStrings. Ideally I would like ByteParser to be agnostic about the use of lazy versus strict ByteStrings. Is this a sensible and/or possible thing to do? You could make your binary parser polymorphic on the string type, and used a String class that both bytestrings are instances of. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [solved] Re: [Haskell-cafe] c2hs and cabal?
On Wed, Nov 29, 2006 at 01:12:50PM +, Duncan Coutts wrote: http://www.haskell.org/cabal/release/latest/doc/users-guide/x30.html#buildinfo Section 2.1.4, though I do notice that the link to the full list of extensions is broken. This version works (and looks better too): http://www.haskell.org/ghc/docs/latest/html/Cabal/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] generating javascript
2006/11/29, jeff p [EMAIL PROTECTED]: This seems to contain just what I was looking for. Although I'm not using HSP, it looks like the HSPClientside library can be used (in conjunction with Text.XHtml) to generate webpages with embedded scripts. It sure should be possible to use HSPClientside with Text.XHtml, but off course with exceptions to all Haskell Server Pages (HSP) specific functions. Anyway I encourage you to have a look at HSP as well :-) It's quite nice to be able to use regular XML syntax within the Haskell code. /Joel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] generating javascript
Hi Anyway I encourage you to have a look at HSP as well :-) It's quite nice to be able to use regular XML syntax within the Haskell code. I think it should be entirely possible to use Haskell with Yhc and HSX (http://www.cs.chalmers.se/~d00nibro/haskell-src-exts/), so you can still write proper XML for your client side HTML. This is the way Hoogle 4 is going to be written. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re : Defining Cg, HLSL style vectors in Haskell
[snip] If you're doing matrix transformations, you might also like to consider using separate PositionN and DirectionN types instead of VecN to make use of the type system to catch some math bugs but I haven't looked into this myself yet so I don't know whether this would be practical or not. Indeed, not only bug catching : actually, some operations on points, vectors and normals have to be done differently. Thu Best regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] known, I know: class contexts and mutual recursion
Hi folks I just tripped over the Contexts differ in length error message. I know it's not a new problem, but I thought I'd enquire as to its status. For those of you who haven't seen it, here's an example, contrived but compact. data Thing = Val Int | Grok Thing (Maybe Int - Int) eval :: Monad m = Thing - m Int eval (Val i) = return i eval (Grok t f) = return (f (eval t)) My eval function compiles ok. See? The recursive call to eval targets the Maybe monad, so I get *Mmm eval (Grok (Val 5) (maybe 0 (1 +))) :: Maybe Int Just 6 However, when I try to decompose eval as a pair of mutually recursive functions, namely foo :: Monad m = Thing - m Int foo (Val i) = return i foo (Grok t f) = return (goo t f) goo :: Thing - (Maybe Int - Int) - Int goo t f = f (foo t) I get Mmm.lhs:15:1: Contexts differ in length When matching the contexts of the signatures for foo :: forall (m :: * - *). (Monad m) = Thing - m Int goo :: Thing - (Maybe Int - Int) - Int The signature contexts in a mutually recursive group should all be identical Poking about on the web, I got the impression that this was a known infelicity in ghc 6.4 (which I'm using), due to be ironed out. However, an early-adopting colleague with 6.6 alleges that foo-goo is still poisonous. I'm wondering what the story is. I mean, is there some nasty problem lurking here which prevents the lifting of this peculiar restriction? I'm not in a panic about this. I have a workaround for the problem as I encountered it in practice. Mind you, it's the sort of thing that's likely to happen more often, the more you localise the effects you tend to use. In the above, goo doesn't throw exceptions; rather, because goo has a handler, it can offer a /local/ exception-throwing capability to foo. Curious Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Difficult memory leak in array processing
I personally find doing higher order functions with IO extremely difficult, and the resulting compiler errors are often downright scary. But this is probably a direct consequence my rather limited understanding of the monadic operators that the do notion hides. It seems that one has to be /very/ good in Haskell before one can do IO effectively. Hmm. Well, as good as a necromancer has to be :) But seriously, I think the most mind boggling point about IO actions is that those are higher order, too. I for myself have taken the point of view that values of type (IO a) are just plans that will be executed when the main Haskell program has done its work. The programs task is to assemble the main plan by sequencing smaller plans with (=). But back to the point, using Haskell lists for representing a largish buffer of, say, 16-bit samples that is constantly being refreshed from hard disk and sent into the sound system for playback would probably be inefficient beyond imagination. Lists are indeed not suited for massive byte crunching. If they fit into a black box, you can of course outsource things into C. In case you were writing a track scheduler à la iTunes, the black box most likely would be a single function (playSoundFile) which does the job of handling data from disk to the sound card. Actual sound processing with Haskell functions is more involved. As already said, specifying loops over the samples as higher order functions will save you a lot of headaches. The point is that one just cannot start writing Haskell code and hope that it will run as fast as a tight loop in C. Instead, one should do aggressive optimizations at a few critical points only. And these are exactly the higher order loops. I have to admit that (accumM) is not very fast because it is able to change data at arbitrary indexes which therefore have to be kept around. Most often, you want to process each index exactly once which is better expressed as a (map) or a (fold). As Bulat and Duncan already said, Data.ByteString does exactly this for arrays of bytes. Using it or the generalization promised by Duncan is likely to be the best way to go. On the implementation level, lazy evaluation is in the way when crunching bytes. So be sure to tell GHC to make things strict and to unbox and inline everything it can put its hands on by giving appropriate command line options. As others already pointed out, the details are on http://haskell.org/haskellwiki/Performance As a first test, you may want to compile your original code with -O3 -optc-O3 -funfolding-use-threshold=16 and explore what happens. GHC does a good job with strictness analysis and it's of no use to drown your code in strictness annotations. Of course, some well placed ones may hint GHC about things it overlooked. To mention yet another approach, the image synthesis library Pan http://conal.net/pan/ pretends that the programmer writes ordinary Haskell functions, but under the hood, it's a tiny programming language that gets compiled to C++. Of course, the main point is that the image synthesis combinators are strictly less powerful than full Haskell. But as the full power is unneeded in that context, this doesn't hurt. While there are audio related projects, http://haskell.org/haskellwiki/Libraries_and_tools/Music_and_sound I don't know whether they focus on speed. Regards, afpelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Defining Cg, HLSL style vectors in Haskell
On 11/29/06, Krasimir Angelov [EMAIL PROTECTED] wrote: Hi Slavomir, On 11/28/06, Slavomir Kaslev [EMAIL PROTECTED] wrote: instance Num Float3 where . signum a | a == Float3 0 0 0 = 0 | otherwise = 1 signum has a natural generalization for vectors. signum v = vector with the same direction as v but with |v| = 1 where |v| is the absolute length of v. The problematic function in Num is abs. Ideally abs should be defined as: abs v = |v| but its type is Float3 - Float while the Num class requires Float3 - Float3. You mean signum = normalize? What do you think of my comments here: After giving some thought on signum, I got to the point, that signum should be defined so that abs x * signum x = x holds. So it can be defined as signum (Vec2 x y) = Vec 2 (signum x) (signum y). It turns out that all the functions in Num, Floating, etc. classes can be given meaningful definitions for vectors in this pattern. That is f (Vecn x1 x2 .. xn) = Vecn (f x1) ... (f xn). And all expected laws just work. One can think of that like the way SIMD processor works, it does the same operations as on floats but on four floats at parallel. I think this is the way to define vector instances for Num, Floating, etc. For vector specific operations, such as normalize, len, dot, cross, etc. are declared in class Vector. -- Slavomir Kaslev ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Defining Cg, HLSL style vectors in Haskell
It is possible of course but your definition doesn't correspond to any operation in the usual vector algebra. By the way how do you define (*)? Isn't it 3D vector multiplication? Krasimir On 11/29/06, Slavomir Kaslev [EMAIL PROTECTED] wrote: You mean signum = normalize? What do you think of my comments here: After giving some thought on signum, I got to the point, that signum should be defined so that abs x * signum x = x holds. So it can be defined as signum (Vec2 x y) = Vec 2 (signum x) (signum y). It turns out that all the functions in Num, Floating, etc. classes can be given meaningful definitions for vectors in this pattern. That is f (Vecn x1 x2 .. xn) = Vecn (f x1) ... (f xn). And all expected laws just work. One can think of that like the way SIMD processor works, it does the same operations as on floats but on four floats at parallel. I think this is the way to define vector instances for Num, Floating, etc. For vector specific operations, such as normalize, len, dot, cross, etc. are declared in class Vector. -- Slavomir Kaslev ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Difficult memory leak in array processing
On Wed, 2006-11-29 at 20:27 +0100, [EMAIL PROTECTED] wrote: On the implementation level, lazy evaluation is in the way when crunching bytes. Something I rather enjoyed when hacking on the ByteString lib is finding that actually lazy evaluation is great when crunching bytes, though you do need to know exactly when to use it. Lazy ByteStrings rely on lazy evaluation of course. Demanding a lazy ByteString alternates between strictly filling in big chunks of data in memory with lazily suspending before producing the next chunk. As many people have observed before, FP optimisation is to a great extent about thinking more carefully about a better evaluation order for a computation and making some bits stricter and some bits lazier to get that better evaluation order. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] generating javascript
Hello, It sure should be possible to use HSPClientside with Text.XHtml, but off course with exceptions to all Haskell Server Pages (HSP) specific functions. Anyway I encourage you to have a look at HSP as well :-) It's quite nice to be able to use regular XML syntax within the Haskell code. Currently I am dynamically generating webpages using HAppS; thus my desire for a combinator library for use directly in Haskell. If I start using static web pages then I'll likely use HSP. Is the JavaScript embedding in HSPClientside essentially the same as the embedding explained in Broberg's thesis? thanks, Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell source transformer?
Hi, In order to automatize the creation of W3C DOM typesafe wrapper (this is needed for my Haskell-Javascript stuff) I am processing the OMG IDL files that contain interface definitions for DOM methods and attributes with HDirect. It works in general (for some reason it didn't like boolean type, so I used a preprocessor to redefine it as Boolean), and outputs some Haskell code full of foreign calls, yet it contains what I need: type signatures. For example, for the method appendChild it outputs: appendChild :: Node a1 - Node a0 - Prelude.IO (Node ()) appendChild newChild iptr = do o_appendChild - Com.invokeIt (\ methPtr iptr - Foreign.ForeignPtr.withForeignPtr newChild (\ new unmarshallNode o_appendChild (above lines of code may be truncated, they are just for illustration) This is almost it, but I need to replace the return type (using the JS monad instead of IO), and replace the method implementation with something else, based on unsafeJS. In some other cases I may need to modify type declarations, etc. I know there is a Haskell syntax parser around (maybe, more than one). Does anybody know of any utility based on such parser that does things I need, or rather a library on top of the parser? I just would like to avoid reinventing the wheel. Last thing I want to do is to change sources of HDirect. Thanks. -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
