Hmm, what license to use?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
97 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

Wolfgang Jeltsch-2
Am Donnerstag, 2. Oktober 2008 20:33 schrieben Sie:
> Wolfgang Jeltsch wrote:
> > You mean shared libraries without the opportunity to inline library code?
> > This would result in a huge performance loss, I think.
>
> Usually _mild_ performance loss, in exchange for major code-size
> savings, I would think. C obviously has worked quite fine under exactly
> this restraint (though C implementations obviously aren't built to take
> as great advantage of inlining library code as Haskell may be).

I think that the performance loss is much higher in the case of Haskell
because of Lazy Evaluation, massive use of higher order functions and
possibly more.  Maybe one of the GHC developers could comment on this?

Best wishes,
Wolfgang
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

David Leimbach
In reply to this post by Wolfgang Jeltsch-2


On Thu, Oct 2, 2008 at 11:25 AM, Wolfgang Jeltsch <[hidden email]> wrote:
Am Dienstag, 30. September 2008 00:18 schrieb Duncan Coutts:
> Yet another reason for getting dynamic linking / shared libs for Haskell
> packages working reliably on all platforms.

You mean shared libraries without the opportunity to inline library code?
This would result in a huge performance loss, I think.

Not all platforms even have shared libraries.  Assuming that mechanism exists to begin with is somewhat flawed if you're interested in wide portability.
 


Best wishes,
Wolfgang
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: Hmm, what license to use?

Bulat Ziganshin-2
In reply to this post by Wolfgang Jeltsch-2
Hello Wolfgang,

Thursday, October 2, 2008, 11:25:52 PM, you wrote:

>> > You mean shared libraries without the opportunity to inline library code?
>> > This would result in a huge performance loss, I think.
>>
>> Usually _mild_ performance loss, in exchange for major code-size
>> savings, I would think. C obviously has worked quite fine under exactly
>> this restraint (though C implementations obviously aren't built to take
>> as great advantage of inlining library code as Haskell may be).

> I think that the performance loss is much higher in the case of Haskell
> because of Lazy Evaluation, massive use of higher order functions and
> possibly more.  Maybe one of the GHC developers could comment on this?

and type classes. once i've forget to addinline pragma, my program
(serializing arrays) becomes 200x slower. it was due to use of
hieararchy of several type classes. afaiu, their dictionaries are also
lazily evaluated plus we have usual overhead of haskell closures that
are ready for particular application

--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

Don Stewart-2
bulat.ziganshin:

> Hello Wolfgang,
>
> Thursday, October 2, 2008, 11:25:52 PM, you wrote:
>
> >> > You mean shared libraries without the opportunity to inline library code?
> >> > This would result in a huge performance loss, I think.
> >>
> >> Usually _mild_ performance loss, in exchange for major code-size
> >> savings, I would think. C obviously has worked quite fine under exactly
> >> this restraint (though C implementations obviously aren't built to take
> >> as great advantage of inlining library code as Haskell may be).
>
> > I think that the performance loss is much higher in the case of Haskell
> > because of Lazy Evaluation, massive use of higher order functions and
> > possibly more.  Maybe one of the GHC developers could comment on this?
>
> and type classes. once i've forget to addinline pragma, my program
> (serializing arrays) becomes 200x slower. it was due to use of
> hieararchy of several type classes. afaiu, their dictionaries are also
> lazily evaluated plus we have usual overhead of haskell closures that
> are ready for particular application

How long ago was this, Bulat? I'd be interested to know if any
of the compilers since 6.8.x, with all its inlining improvements,
exhibited the same fragility.

If I recall correctly, your experiments were around the 6.4.x series of
compilers?

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: Hmm, what license to use?

Bulat Ziganshin-2
Hello Don,

Friday, October 3, 2008, 2:22:49 AM, you wrote:

>> and type classes. once i've forget to addinline pragma, my program
>> (serializing arrays) becomes 200x slower. it was due to use of
>> hieararchy of several type classes. afaiu, their dictionaries are also
>> lazily evaluated plus we have usual overhead of haskell closures that
>> are ready for particular application

> How long ago was this, Bulat? I'd be interested to know if any
> of the compilers since 6.8.x, with all its inlining improvements,
> exhibited the same fragility.

> If I recall correctly, your experiments were around the 6.4.x series of
> compilers?

yes, exactly. not tried with anything newer, so can't say anything
about it


--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Hmm, what license to use?

Mitchell, Neil
In reply to this post by Wolfgang Jeltsch-2

Hi


> > > You mean shared libraries without the opportunity to
> inline library code?
> > > This would result in a huge performance loss, I think.
> >
> > Usually _mild_ performance loss, in exchange for major code-size
> > savings, I would think. C obviously has worked quite fine under
> > exactly this restraint (though C implementations obviously aren't
> > built to take as great advantage of inlining library code
> as Haskell may be).
>
> I think that the performance loss is much higher in the case
> of Haskell because of Lazy Evaluation, massive use of higher
> order functions and possibly more.

Example 1:

foo x | "test" `isPrefixOf` xs = ...
        | otherwise = ...

If you have cross-module inlining, you get the rather obvious if like
construct. If you don't, you have to evaluate otherwise and test its
value.

Example 2:

(a :: Int) + b

If you have cross-module specialisation you get a primitive integer
arithmetic instruction (possibly with a bit of unboxing, although often
not). If you don't, you get a dictionary lookup, followed by a higher
order application.

One reason cross-module inlining is essential is that many Haskell
functions don't do very much, think of (+), (||), (>>), not, otherwise
etc. In C these would be built-in's, so are always available to the
optimiser (and usually just one instruction), in Haskell you need to get
them from the Prelude.

Thanks

Neil

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

Vo Minh Thu
2008/10/3 Mitchell, Neil <[hidden email]>:

>
> Hi
>
>
>> > > You mean shared libraries without the opportunity to
>> inline library code?
>> > > This would result in a huge performance loss, I think.
>> >
>> > Usually _mild_ performance loss, in exchange for major code-size
>> > savings, I would think. C obviously has worked quite fine under
>> > exactly this restraint (though C implementations obviously aren't
>> > built to take as great advantage of inlining library code
>> as Haskell may be).
>>
>> I think that the performance loss is much higher in the case
>> of Haskell because of Lazy Evaluation, massive use of higher
>> order functions and possibly more.
>
> Example 1:
>
> foo x | "test" `isPrefixOf` xs = ...
>        | otherwise = ...
>
> If you have cross-module inlining, you get the rather obvious if like
> construct. If you don't, you have to evaluate otherwise and test its
> value.
>
> Example 2:
>
> (a :: Int) + b
>
> If you have cross-module specialisation you get a primitive integer
> arithmetic instruction (possibly with a bit of unboxing, although often
> not). If you don't, you get a dictionary lookup, followed by a higher
> order application.
>
> One reason cross-module inlining is essential is that many Haskell
> functions don't do very much, think of (+), (||), (>>), not, otherwise
> etc. In C these would be built-in's, so are always available to the
> optimiser (and usually just one instruction), in Haskell you need to get
> them from the Prelude.

What happens in the C++ world where good chunk of functionnalities are
in header files (templates or inline methods);
is there the same LGPL problem that the one discussed here w.r.t.
static/shared linking ?

Thanks,
Thu
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

Simon Marlow-5
In reply to this post by Magnus Therning
Magnus Therning wrote:

> On Wed, Oct 1, 2008 at 6:03 PM, Simon Marlow <[hidden email]> wrote:
> [..]
>> Dynamic linking doesn't solve all the problems, we still have the problem
>> that GHC does a lot of cross-module inlining, regardless of whether dynamic
>> linking is used.  However, I really would like to have a way to have
>> complete control over what is exposed across a package boundary.  We need
>> this not just for licensing reasons, but also for making a dynamic library
>> with a fixed ABI, so it can be upgraded later.
>
> I have a really hard time following this.  Are you seriously saying
> that GHC is inlining code from modules _and_ link dynamically at the
> same time.  That seems like a remarkably strange thing to do, or maybe
> I'm just missing something.

That's exactly what would happen, if we shipped dynamic linking support
with GHC as it stands.  It's just a linking mechanism, an alternative to
static linking, and has no impact on the amount or nature of
inter-module optimisation that GHC does.

> My understanding from another thread on here was that dynamic linking
> isn't working reliably, not even on Windows, where it once was
> supported.  It has never worked on any other platform.

The fundamental mechanisms are working on {x86, x86-64, PPC, PPC64} /
{Linux, OS X, Windows} and possibly other OSs.  However right now you
need a few small patches to the source tree to get it to build.  Most of
the unresolved issues are around how to construct binary installs, and
how executables will find their libraries when the run (e.g. if you
install GHC privately in your home directory).

Cheers,
        Simon
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

Magnus Therning
On Fri, Oct 3, 2008 at 12:59 PM, Simon Marlow <[hidden email]> wrote:

> Magnus Therning wrote:
>>
>> On Wed, Oct 1, 2008 at 6:03 PM, Simon Marlow <[hidden email]>
>> wrote:
>> [..]
>>>
>>> Dynamic linking doesn't solve all the problems, we still have the problem
>>> that GHC does a lot of cross-module inlining, regardless of whether
>>> dynamic
>>> linking is used.  However, I really would like to have a way to have
>>> complete control over what is exposed across a package boundary.  We need
>>> this not just for licensing reasons, but also for making a dynamic
>>> library
>>> with a fixed ABI, so it can be upgraded later.
>>
>> I have a really hard time following this.  Are you seriously saying
>> that GHC is inlining code from modules _and_ link dynamically at the
>> same time.  That seems like a remarkably strange thing to do, or maybe
>> I'm just missing something.
>
> That's exactly what would happen, if we shipped dynamic linking support with
> GHC as it stands.  It's just a linking mechanism, an alternative to static
> linking, and has no impact on the amount or nature of inter-module
> optimisation that GHC does.
Ah, now I understand.  The object for GHC would be to reduce the
system-wide use of memory rather than substitutability of DLLs then,
right?

Why would it be interesting to have sharable objects without substitutability?

/M

--
Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
magnus@therning.org          Jabber: magnus@therning.org
http://therning.org/magnus         identi.ca|twitter: magthe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

Duncan Coutts
On Fri, 2008-10-03 at 16:25 +0100, Magnus Therning wrote:

> Ah, now I understand.  The object for GHC would be to reduce the
> system-wide use of memory rather than substitutability of DLLs then,
> right?
>
> Why would it be interesting to have sharable objects without substitutability?

Hello world and plugins you want to load into foreign programs would be
a few k rather than a few hundred or a few thousand k.

Being able to substitute is something that may be possible later, at
least for some packages. Simon has been mulling over some of the
possibilities here. One idea is if you specifically want to build a .so
or .dll with a stable ABI then you could declare that's what you want to
do, and then not do cross-module inlining by default (except for those
functions marked INLINE) then you can guarantee you're not breaking ABI
so long as you do not change the types of exported functions or the
implementations of functions marked INLINE. Extending the ABI in a
compatible way needs more thought about a suitable mechanism.

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

Simon Marlow-7
In reply to this post by Magnus Therning
Magnus Therning wrote:

> On Fri, Oct 3, 2008 at 12:59 PM, Simon Marlow <[hidden email]> wrote:
>> Magnus Therning wrote:
>>> On Wed, Oct 1, 2008 at 6:03 PM, Simon Marlow <[hidden email]>
>>> wrote:
>>> [..]
>>>> Dynamic linking doesn't solve all the problems, we still have the problem
>>>> that GHC does a lot of cross-module inlining, regardless of whether
>>>> dynamic
>>>> linking is used.  However, I really would like to have a way to have
>>>> complete control over what is exposed across a package boundary.  We need
>>>> this not just for licensing reasons, but also for making a dynamic
>>>> library
>>>> with a fixed ABI, so it can be upgraded later.
>>> I have a really hard time following this.  Are you seriously saying
>>> that GHC is inlining code from modules _and_ link dynamically at the
>>> same time.  That seems like a remarkably strange thing to do, or maybe
>>> I'm just missing something.
>> That's exactly what would happen, if we shipped dynamic linking support with
>> GHC as it stands.  It's just a linking mechanism, an alternative to static
>> linking, and has no impact on the amount or nature of inter-module
>> optimisation that GHC does.
>
> Ah, now I understand.  The object for GHC would be to reduce the
> system-wide use of memory rather than substitutability of DLLs then,
> right?
>
> Why would it be interesting to have sharable objects without substitutability?

It'll make our binary distributions a lot smaller for one thing.  Also, the
on-disk size of binaries will be a lot smaller - this is something you
notice if you run a GHC test suite, for example.

Also, the GHCi binary contains the base package, but loads up another
complete copy when it starts up.  And if you load up the GHC package inside
GHCi, then you have two complete copies of GHC in memory.  Dynamic linking
fixes all this.

Cheers,
        Simon

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

Wolfgang Jeltsch-2
In reply to this post by Vo Minh Thu
Am Freitag, 3. Oktober 2008 13:36 schrieben Sie:
> […]

> What happens in the C++ world where good chunk of functionnalities are
> in header files (templates or inline methods);
> is there the same LGPL problem that the one discussed here w.r.t.
> static/shared linking ?

I've never heard about problems with macros etc. but I think that the LGPL is
problematic if you use templates.

Best wishes,
Wolfgang
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

David Leimbach
In reply to this post by Vo Minh Thu


On Fri, Oct 3, 2008 at 4:36 AM, minh thu <[hidden email]> wrote:
2008/10/3 Mitchell, Neil <[hidden email]>:
>
> Hi
>
>
>> > > You mean shared libraries without the opportunity to
>> inline library code?
>> > > This would result in a huge performance loss, I think.
>> >
>> > Usually _mild_ performance loss, in exchange for major code-size
>> > savings, I would think. C obviously has worked quite fine under
>> > exactly this restraint (though C implementations obviously aren't
>> > built to take as great advantage of inlining library code
>> as Haskell may be).
>>
>> I think that the performance loss is much higher in the case
>> of Haskell because of Lazy Evaluation, massive use of higher
>> order functions and possibly more.
>
> Example 1:
>
> foo x | "test" `isPrefixOf` xs = ...
>        | otherwise = ...
>
> If you have cross-module inlining, you get the rather obvious if like
> construct. If you don't, you have to evaluate otherwise and test its
> value.
>
> Example 2:
>
> (a :: Int) + b
>
> If you have cross-module specialisation you get a primitive integer
> arithmetic instruction (possibly with a bit of unboxing, although often
> not). If you don't, you get a dictionary lookup, followed by a higher
> order application.
>
> One reason cross-module inlining is essential is that many Haskell
> functions don't do very much, think of (+), (||), (>>), not, otherwise
> etc. In C these would be built-in's, so are always available to the
> optimiser (and usually just one instruction), in Haskell you need to get
> them from the Prelude.

What happens in the C++ world where good chunk of functionnalities are
in header files (templates or inline methods);
is there the same LGPL problem that the one discussed here w.r.t.
static/shared linking ?

I don't know what happens on platforms that don't have shared libraries with LGPL.  If you build stuff statically, I'm pretty sure you can't claim stuff is loosely coupled.

Dave
 

Thanks,
Thu
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

Bugzilla from jonathanccast@fastmail.fm
On Fri, 2008-10-03 at 10:08 -0700, David Leimbach wrote:

>
>
> On Fri, Oct 3, 2008 at 4:36 AM, minh thu <[hidden email]> wrote:
>         2008/10/3 Mitchell, Neil <[hidden email]>:
>        
>         >
>         > Hi
>         >
>         >
>         >> > > You mean shared libraries without the opportunity to
>         >> inline library code?
>         >> > > This would result in a huge performance loss, I think.
>         >> >
>         >> > Usually _mild_ performance loss, in exchange for major
>         code-size
>         >> > savings, I would think. C obviously has worked quite fine
>         under
>         >> > exactly this restraint (though C implementations
>         obviously aren't
>         >> > built to take as great advantage of inlining library code
>         >> as Haskell may be).
>         >>
>         >> I think that the performance loss is much higher in the
>         case
>         >> of Haskell because of Lazy Evaluation, massive use of
>         higher
>         >> order functions and possibly more.
>         >
>         > Example 1:
>         >
>         > foo x | "test" `isPrefixOf` xs = ...
>         >        | otherwise = ...
>         >
>         > If you have cross-module inlining, you get the rather
>         obvious if like
>         > construct. If you don't, you have to evaluate otherwise and
>         test its
>         > value.
>         >
>         > Example 2:
>         >
>         > (a :: Int) + b
>         >
>         > If you have cross-module specialisation you get a primitive
>         integer
>         > arithmetic instruction (possibly with a bit of unboxing,
>         although often
>         > not). If you don't, you get a dictionary lookup, followed by
>         a higher
>         > order application.
>         >
>         > One reason cross-module inlining is essential is that many
>         Haskell
>         > functions don't do very much, think of (+), (||), (>>), not,
>         otherwise
>         > etc. In C these would be built-in's, so are always available
>         to the
>         > optimiser (and usually just one instruction), in Haskell you
>         need to get
>         > them from the Prelude.
>        
>        
>         What happens in the C++ world where good chunk of
>         functionnalities are
>         in header files (templates or inline methods);
>         is there the same LGPL problem that the one discussed here
>         w.r.t.
>         static/shared linking ?
>
>
> I don't know what happens on platforms that don't have shared
> libraries with LGPL.  If you build stuff statically, I'm pretty sure
> you can't claim stuff is loosely coupled.

What I've always heard is that in that case you have to distribute
object files.

This would work for Haskell, except that changing the distributed
library is still liable to invalidate the object files, due to
cross-module inlining.

jcc


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

Micah Cowan
In reply to this post by Wolfgang Jeltsch-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wolfgang Jeltsch wrote:

> Am Donnerstag, 2. Oktober 2008 20:33 schrieben Sie:
>> Wolfgang Jeltsch wrote:
>>> You mean shared libraries without the opportunity to inline library code?
>>> This would result in a huge performance loss, I think.
>> Usually _mild_ performance loss, in exchange for major code-size
>> savings, I would think. C obviously has worked quite fine under exactly
>> this restraint (though C implementations obviously aren't built to take
>> as great advantage of inlining library code as Haskell may be).
>
> I think that the performance loss is much higher in the case of Haskell
> because of Lazy Evaluation, massive use of higher order functions and
> possibly more.  Maybe one of the GHC developers could comment on this?

Perhaps the best approach currently for creating dynamically loadable
modules in Haskell is to expose the interface via FFI, then? (I suspect
that in most cases, you'd want to provide that as an option, but of
course not as the only means of interfacing with the library, for those
who don't want to make the DLL-vs-optimizations tradeoff.)

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI5lq/7M8hyUobTrERAn7aAJwPz4wbu0W4RPNhlgKGmd+2glZDewCfbi9d
LQtahiILQg83vkzyfAR2BV4=
=mjFe
-----END PGP SIGNATURE-----
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

Mads Lindstrøm
In reply to this post by Gour-3
Hi

Gour wrote:
> >>>>> "Don" == Don Stewart <[hidden email]> writes:
>
> Don>     * Only a small percent of Haskell libarires are LGPL, and
> Don> nothing for which we don't have workarounds (e.g. HDBC vs
> Don> galois-sqlite3 vs takusen).
>
> Hmm, Gtk2Hs & wxhaskell - major GUI libs...

wxHaskell uses a modified LGPL license (wxWidgets license). One that
allows static linking. See
http://www.haskell.org/haskellwiki/WxHaskell/License . From the
description of the wxWidgets license
http://www.wxwidgets.org/about/newlicen.htm :

"The wxWindows Licence is essentially the L-GPL (Library General Public
Licence), with an exception stating that derived works in binary form
may be distributed on the user's own terms. This is a solution that
satisfies those who wish to produce GPL'ed software using wxWidgets, and
also those producing proprietary software."


Greetins,

Mads Lindstrøm

>
> Sincerely,
> Gour
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

David Virebayre
There's an article on slashdot about a developper that has a dilemna
with his BSD-licenced work, I thought that might be relevant to this
thread :

http://ask.slashdot.org/article.pl?sid=08/10/05/1317252
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12345