The Lisp Curse

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

The Lisp Curse

Andrew Coppin
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

Some of you might have seen this. Here's the short version:

   Lisp is so powerful that it discourages reuse. Why search for and
reuse an existing implementation, when it's so trivially easy to
reimplement exactly what you want yourself? The net result is a maze of
incompatible libraries which each solve a different 80% of the same problem.

To all the people who look at Hackage, see that there are 6 different
libraries for processing Unicode text files, and claim that this is
somehow a *good* thing, I offer the above essay as a counter-example.

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

Re: The Lisp Curse

Vo Minh Thu
2011/5/19 Andrew Coppin <[hidden email]>:

> http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
>
> Some of you might have seen this. Here's the short version:
>
>  Lisp is so powerful that it discourages reuse. Why search for and reuse an
> existing implementation, when it's so trivially easy to reimplement exactly
> what you want yourself? The net result is a maze of incompatible libraries
> which each solve a different 80% of the same problem.
>
> To all the people who look at Hackage, see that there are 6 different
> libraries for processing Unicode text files, and claim that this is somehow
> a *good* thing, I offer the above essay as a counter-example.

Hi Andrew,

So what exactly is the problem on hackage and what do you propose as a solution?

Surely you don't want people to upload a library on hackage only once
it is perfect (nor do you think such a perfect, one-size-fits-all
library might exist)?

I haven't read the provided link but I also guess you don't _really_
mean that the referred packages on hackage were 'so trivially easy to
reimplement', nor that it is not possible to use them together...

Cheers,
Thu

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

Re: The Lisp Curse

Serguey Zefirov
In reply to this post by Andrew Coppin
I think this is much less applicable to Haskell than to Lisp.

I think that most of intra-incompatibilities of Lisp stem from side
effects. The rest is mostly due to (relatively) weak type system which
let some errors slip.

And remaining percent or two can be attributed to the power of Lisp. ;)

2011/5/19 Andrew Coppin <[hidden email]>:

> http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
>
> Some of you might have seen this. Here's the short version:
>
>  Lisp is so powerful that it discourages reuse. Why search for and reuse an
> existing implementation, when it's so trivially easy to reimplement exactly
> what you want yourself? The net result is a maze of incompatible libraries
> which each solve a different 80% of the same problem.
>
> To all the people who look at Hackage, see that there are 6 different
> libraries for processing Unicode text files, and claim that this is somehow
> a *good* thing, I offer the above essay as a counter-example.
>
> _______________________________________________
> 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: The Lisp Curse

Serguey Zefirov
In reply to this post by Vo Minh Thu
2011/5/19 Vo Minh Thu <[hidden email]>:

> 2011/5/19 Andrew Coppin <[hidden email]>:
>> http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
>>
>> Some of you might have seen this. Here's the short version:
>>
>>  Lisp is so powerful that it discourages reuse. Why search for and reuse an
>> existing implementation, when it's so trivially easy to reimplement exactly
>> what you want yourself? The net result is a maze of incompatible libraries
>> which each solve a different 80% of the same problem.
>>
>> To all the people who look at Hackage, see that there are 6 different
>> libraries for processing Unicode text files, and claim that this is somehow
>> a *good* thing, I offer the above essay as a counter-example.
>
> So what exactly is the problem on hackage and what do you propose as a solution?

The problem is that you have to try several packages before you get to
the stable point.

The solution... I think that some ratings, like "used directly by ###
packages/projects and indirectly by ###" would be nice, but not much.

As for me, I like the diversity of packages. They attack close
problems from different fronts. They express different ideas and
views. I like all that.

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

Re: The Lisp Curse

Gilberto Garcia
In reply to this post by Vo Minh Thu
I think what Andrew meant is that it's not a good idea to have big
pile of different implementations of the same library, and all trying
to solve the very same problem.

I see this kind of problem in the java community. It seems that
developers have a need to create everything from scratch more than
making existing ones better.

Short history, for example, why do we have to have N libraries to read
a file? can't we have just one damn good one?

Cheers

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

Re: The Lisp Curse

Daniel Patterson
Correct my ignorance as I'm rather new around here, but I'm not sure if I actually think this happens that much.

Different approaches are often put forth, which does mean that there are incompatible libraries that fill the same space for a while, but it seems that once it becomes clear what the best approach is, that becomes pretty well accepted. Are there really example of multiple libraries that use the same approach to solve the same problem that are incompatible and actively used? Right now there are a bunch of iteratee/enumerator/whatever term you want to call it libraries, but those are new ideas, and it isn't clear yet what the best approach is.

In an open source community, there will always be multiple approaches to common problems. If as soon as one person came up with a solution, all others had to build upon that, there would be no progress, as no one would be able to try out new ideas.

What is important is that there is visibility for packages so that people can see what else is out there and can decide if it makes the most sense to:
A. use an existing solution
B. improve an existing solution
C. start from scratch, because of wanting a fundamentally different approach.

I think hackage provides that. So what's the problem?

> Short history, for example, why do we have to have N libraries to read
> a file? can't we have just one damn good one?

The only way to get there is to have many solutions and then decide what the best one is!

Just my .02

On May 19, 2011, at 2:56 PM, Gilberto Garcia wrote:

> I think what Andrew meant is that it's not a good idea to have big
> pile of different implementations of the same library, and all trying
> to solve the very same problem.
>
> I see this kind of problem in the java community. It seems that
> developers have a need to create everything from scratch more than
> making existing ones better.
>
>
> Cheers
>
> _______________________________________________
> 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: The Lisp Curse

Felipe Lessa
In reply to this post by Serguey Zefirov
On Thu, May 19, 2011 at 3:50 PM, Serguey Zefirov <[hidden email]> wrote:
> The solution... I think that some ratings, like "used directly by ###
> packages/projects and indirectly by ###" would be nice, but not much.
>
> As for me, I like the diversity of packages. They attack close
> problems from different fronts. They express different ideas and
> views. I like all that.

Regarding the Unicode problem, there is a standard solution today: use
the text package.  Yes, you may use other libraries, but text is the
recommended one.

The problem is that no one coming to Hackage discovers that on Hackage
itself.  You have to dig the Internet to find some blog post telling
you what to do.  And hope that the blog post isn't old.

So we really need a way of raking libraries in Hackage.  We already
have the Haskell Platform, which is really really nice, but the HP
can't embrace everything.  For everything outside HP, a ranking system
is needed.

Cheers! =)

--
Felipe.

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

Re: The Lisp Curse

Stephen Tetley-2
In reply to this post by Andrew Coppin
Och Mr Coppin

Lisp is a fine language, but all "Lisp" essays you'll find on the
internet except Richard Gabriel's "Worse is Better" are absolute tosh.

Read Olin Shiver's introduction to SRE regex notation for an
intelligent contribution to the "6 different libraries" problem you
seem to be having, rather than some cargo cultist muddy thinking.

http://www.scsh.net/docu/post/sre.html

By the way, referencing the original article circa half way down -
didn't Mark P. Jones write Gofer and the original Hugs by himself  -
people actually used those rather than Qi.

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

Re: The Lisp Curse

Don Stewart
This is classic community trolling behavior, Andrew.

You post something inflammatory, questioning the core value of our
project, without a clear argument about why it article relevant, and
then step away to let a monster thread consume everything, as people
try to work out what your point was, not trying to argue a point, or
other wise participate.

Doing this, year after year, is bad for -cafe@ and bad for the
community, and why I don't use -cafe@ for problem solving anymore.

-- Don

I'm glad my mail reader has a "mute" button.

On Thu, May 19, 2011 at 12:39 PM, Stephen Tetley
<[hidden email]> wrote:

> Och Mr Coppin
>
> Lisp is a fine language, but all "Lisp" essays you'll find on the
> internet except Richard Gabriel's "Worse is Better" are absolute tosh.
>
> Read Olin Shiver's introduction to SRE regex notation for an
> intelligent contribution to the "6 different libraries" problem you
> seem to be having, rather than some cargo cultist muddy thinking.
>
> http://www.scsh.net/docu/post/sre.html
>
> By the way, referencing the original article circa half way down -
> didn't Mark P. Jones write Gofer and the original Hugs by himself  -
> people actually used those rather than Qi.
>
> _______________________________________________
> 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: The Lisp Curse

Andrew Coppin
In reply to this post by Gilberto Garcia
On 19/05/2011 07:56 PM, Gilberto Garcia wrote:
> I think what Andrew meant is that it's not a good idea to have big
> pile of different implementations of the same library, and all trying
> to solve the very same problem.

I'm glad somebody understood what I was trying to get at.

I'm not saying that we shouldn't ever have more than one library
tackling the same problem. I'm just saying that when people say "we have
multiple libraries competing to solve this problem, and that's
*great*"... well, not necessarily, no. Obviously there's room for
finding out what the best way to solve the problem is, but ultimately
the ideal is to end up with one library that solves the problem well,
which everybody can use.

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

Re: The Lisp Curse

Andrew Coppin
In reply to this post by Stephen Tetley-2
On 19/05/2011 08:39 PM, Stephen Tetley wrote:
> Och Mr Coppin
>
> Lisp is a fine language, but all "Lisp" essays you'll find on the
> internet except Richard Gabriel's "Worse is Better" are absolute tosh.

This wasn't an attempt to bash Lisp.

This is about all those people who think having multiple libraries which
only solve half the problem is somehow a "good thing".

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

Re: The Lisp Curse

Andrew Coppin
In reply to this post by Don Stewart
On 19/05/2011 08:58 PM, Don Stewart wrote:
> This is classic community trolling behavior, Andrew.

And publicly calling somebody a troll isn't trolling behaviour?

I'm going to answer the rest of this off-list. I'm sure nobody else
wants to hear it.

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

Re: The Lisp Curse

Vagif Verdi
In reply to this post by Andrew Coppin
Andrew, you are being non constructive.

You are saying "We" should.
Who "we", Andrew ? Who are you referring to ?
The developers who created those six different unicode libraries are not united
under any umbrella you can call "we".

The reason those six libraries existis is NOT because some mysterious secret
"we" commitee decided to have six incompatible libraries.

And the maintainers of hackage has better things to do than to police and make
arbitrary decisions what should or should not be "allowed" to hackage.

Also hackage is NOT a standard library, just like SourceForge or Github is not
a standard library. It's just a hosting for haskell libraries.

If you want someone tell you what to use, there's an effort in that direction:
haskell platform. And their attitue is constructive. They don't demand that
"we" (whoever that is) do or do not do something. They compile their own set
of libraries and announce about their existence.

Go lobby them to include one blessed unicode library.


On Thursday, May 19, 2011 01:20:50 PM Andrew Coppin wrote:

> On 19/05/2011 08:39 PM, Stephen Tetley wrote:
> > Och Mr Coppin
> >
> > Lisp is a fine language, but all "Lisp" essays you'll find on the
> > internet except Richard Gabriel's "Worse is Better" are absolute tosh.
>
> This wasn't an attempt to bash Lisp.
>
> This is about all those people who think having multiple libraries which
> only solve half the problem is somehow a "good thing".
>
> _______________________________________________
> 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: The Lisp Curse

Stephen Tetley-2
In reply to this post by Andrew Coppin
On 19 May 2011 21:20, Andrew Coppin <[hidden email]> wrote:

> This is about all those people who think having multiple libraries which
> only solve half the problem is somehow a "good thing".

Och (number 2)

Those people are the Straw Men - you can wave at them from your car
window when you pass them as they stand in farmer's fields, though it
is not out of rudeness that they do not wave back. Alas they are
really made of straw.

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

Re: The Lisp Curse

Andrew Coppin
In reply to this post by Vagif Verdi
On 19/05/2011 09:34 PM, [hidden email] wrote:
> Andrew, you are being non constructive.

It seems I'm being misunderstood.

Some people seem to hold the opinion that more libraries = better. I'm
trying to voice the opinion that there is such a thing as too many
libraries. The article I linked to explains part of why this is the
case, in a better way than I've been able to phrase it myself.

I'm not trying to say "OMG, the way it is now completely sucks!" I'm not
trying to say "you must do X right now!" I'm just trying to put forward
an opinion. The opinion that having too many libraries can be a problem,
which some people don't seem to agree with. (Obviously it isn't *always*
bad, I'm just saying that sometimes it can be.)

That's all I was trying to say.

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

Re: The Lisp Curse

Julian Porter
In reply to this post by Andrew Coppin
>  ultimately the ideal is to end up with one library that solves the problem well, which everybody can use.
>
>
 Nonsense.  One library that everyone can use with either end up being so small in functionality that it's actually useless, or so general that either it requires tons and tons of boilerplate just to use it at all, or it's really about eight libraries rolled into one and so impossible to find your way around.  Whichever, it's not good.  The sweet spot is at the point of maximum tension between generality and simplicity.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: The Lisp Curse

Ketil Malde-5
In reply to this post by Andrew Coppin
Andrew Coppin <[hidden email]> writes:

> I'm trying to voice the opinion that there is such a thing as too many
> libraries. The article I linked to explains part of why this is the
> case, in a better way than I've been able to phrase it myself.

I don't think so, the article seems to talk more about social problems
among lisp users, which it - at least in part - ascribes to the technical
prowess of the language.

I don't think the article makes its point very well, though. For
instance, it uses object orientation as an example, but CLOS is fairly
standard in Lisp, I believe, and the author had to turn to Scheme for
his examples.  The problem again seems to be more social (the lack of an
active committee to do standardizing) than technical.

> The opinion that having too many libraries can be
> a problem, which some people don't seem to agree with.

I don't see how the number of available libraries is a problem in
itself, but it would be nice if hackage or some other resource provided
more help in recommending which library to try first.  We do have
standardization efforts, committees bringing the language forward and an
inclusive and collaborative community.

-k
--
If I haven't seen further, it is by standing in the footprints of giants

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

Re: The Lisp Curse

aditya siram-2
In reply to this post by Julian Porter
I wonder if it would be useful to be able to download and use only necessary modules from Hackage. This way if someone writes, say a superior XML parsing API, and someone else has better generating API, the user can pull just those modules , write the glue and have the best of both worlds.

On the upside this would:
1. Make for a smaller local cabal repository.
2. Mitigate the problem of having to compile a package that has functionality you don't need. MissingH [1] is a good example.
3. Allow you to continue working even if one of the modules doesn't compile. I recently ran into this with liboleg [2] where I only wanted Control.CCCXe, but couldn't "cabal install" it on my system because one of the other modules failed to compile.

-deech

[1] http://hackage.haskell.org/package/MissingH-1.1.0.3
[2] http://hackage.haskell.org/package/liboleg

On Thu, May 19, 2011 at 4:30 PM, Julian Porter <[hidden email]> wrote:
>  ultimately the ideal is to end up with one library that solves the problem well, which everybody can use.
>
>
 Nonsense.  One library that everyone can use with either end up being so small in functionality that it's actually useless, or so general that either it requires tons and tons of boilerplate just to use it at all, or it's really about eight libraries rolled into one and so impossible to find your way around.  Whichever, it's not good.  The sweet spot is at the point of maximum tension between generality and simplicity.
_______________________________________________
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: The Lisp Curse

Daniel Peebles
In reply to this post by Andrew Coppin
The way I understand it, you're saying not that we shouldn't be doing it this way (since it isn't centrally managed, it's the only possible way), but that we shouldn't be "bragging" (for lack of a better word) that we have lots of libraries that do a specific thing. Or if not that, then at least that it isn't a clear win.

I agree that from an end-user's perspective it isn't always a clear win, but I do think that having a bunch of libraries (even ones that do the same thing) an indicator of a healthy, active, and enthusiastic community. Sure, it's decentralized and people will often duplicate effort, but different variations on the same idea can also help explore the design space and will reveal to everyone interested what works and what doesn't.

But yeah, if you want to do X and you encounter 15 libraries that do X and can't find a clear consensus on what's best, I can understand why that might be frustrating. I don't think there's really a clear solution to that though, other than gently encouraging collaboration and scoping out of existing work before starting new work. But people generally hate working with other people's code, so I doubt that'll have much of an effect :)

Dan

On Thu, May 19, 2011 at 4:56 PM, Andrew Coppin <[hidden email]> wrote:
On 19/05/2011 09:34 PM, [hidden email] wrote:
Andrew, you are being non constructive.

It seems I'm being misunderstood.

Some people seem to hold the opinion that more libraries = better. I'm trying to voice the opinion that there is such a thing as too many libraries. The article I linked to explains part of why this is the case, in a better way than I've been able to phrase it myself.

I'm not trying to say "OMG, the way it is now completely sucks!" I'm not trying to say "you must do X right now!" I'm just trying to put forward an opinion. The opinion that having too many libraries can be a problem, which some people don't seem to agree with. (Obviously it isn't *always* bad, I'm just saying that sometimes it can be.)

That's all I was trying to say.


_______________________________________________
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: The Lisp Curse

austin seipp-3
I too am not all that concerned about the library proliferation, and I
think such work can definitely help find the best design for certain
abstractions. There are no less than 3 iteratee libraries - 4
including liboleg's original IterateeM formulation - and a number of
FRP implementations as well, but part of that is because we haven't
found the best designs for such things yet. Doing that will take time
and effort on the part of the community, whether there's 3 competing
libraries or 30.

In the case of Unicode, I think the community has clearly spoken in
its adoption of the `text` package into the Platform, as well as it
being one of the most depended on hackage packages. Certainly the
platform doesn't recommend a 'blessed' package for every need. JSON is
a simple example, and there are many various JSON implementations on
Hackage. Outside of the platform, I think there should definitely be a
better way to communicate to users what library might be best. I don't
know how that would look - Hackage 2 will have commenting and reverse
dependencies I think, but when that future hackage will rise is not
clear.

One thing is for certain: in the Haskell ecosystem, if your code does
not exist on Hackage, and *especially* if it does not use Cabal,
realistically speaking, it is dead as far as the larger community is
concerned (the exception being GHC itself, perhaps. Even gtk2hs - who
was one of the biggest outliers for a long time, now is cabalized.) I
think I would ultimately rather encourage people to submit code - even
if it is small or perhaps duplicate. At least give it and its ideas
the chance to survive, be used and talked about, and die if not -
rather than resign it to such a fate prematurely.

On Thu, May 19, 2011 at 5:00 PM, Daniel Peebles <[hidden email]> wrote:

> The way I understand it, you're saying not that we shouldn't be doing it
> this way (since it isn't centrally managed, it's the only possible way), but
> that we shouldn't be "bragging" (for lack of a better word) that we have
> lots of libraries that do a specific thing. Or if not that, then at least
> that it isn't a clear win.
> I agree that from an end-user's perspective it isn't always a clear win, but
> I do think that having a bunch of libraries (even ones that do the same
> thing) an indicator of a healthy, active, and enthusiastic community. Sure,
> it's decentralized and people will often duplicate effort, but different
> variations on the same idea can also help explore the design space and will
> reveal to everyone interested what works and what doesn't.
> But yeah, if you want to do X and you encounter 15 libraries that do X and
> can't find a clear consensus on what's best, I can understand why that might
> be frustrating. I don't think there's really a clear solution to that
> though, other than gently encouraging collaboration and scoping out of
> existing work before starting new work. But people generally hate working
> with other people's code, so I doubt that'll have much of an effect :)
> Dan
>
> On Thu, May 19, 2011 at 4:56 PM, Andrew Coppin <[hidden email]>
> wrote:
>>
>> On 19/05/2011 09:34 PM, [hidden email] wrote:
>>>
>>> Andrew, you are being non constructive.
>>
>> It seems I'm being misunderstood.
>>
>> Some people seem to hold the opinion that more libraries = better. I'm
>> trying to voice the opinion that there is such a thing as too many
>> libraries. The article I linked to explains part of why this is the case, in
>> a better way than I've been able to phrase it myself.
>>
>> I'm not trying to say "OMG, the way it is now completely sucks!" I'm not
>> trying to say "you must do X right now!" I'm just trying to put forward an
>> opinion. The opinion that having too many libraries can be a problem, which
>> some people don't seem to agree with. (Obviously it isn't *always* bad, I'm
>> just saying that sometimes it can be.)
>>
>> That's all I was trying to say.
>>
>> _______________________________________________
>> 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
>
>



--
Regards,
Austin

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