Quantcast

Proposal: Remove Show and Eq superclasses of Num

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposal: Remove Show and Eq superclasses of Num

Ian Lynagh

Hi all,

I would like to propose that we remove the Show and Eq superclasses from
Num, i.e. change
    class  (Eq a, Show a) => Num a  where
        [...]
to
    class  Num a  where
        [...]


The first 2 attached patches (for base and ghc respectively) remove the
Show constraint. I'm not aware of any justification for why this
superclass makes sense.


The next 2 patches (for base and unix respectively) remove the Eq
constraint. Here's there's some justification in the superclass, as it
makes
    f 5 = ...
work for any Num type, rather than also needing an Eq constraint, but
personally I would be in favour of removing this superclass too.
Noteworthy is that Bits now needs an Eq superclass for the default
methods for 'testBit' and 'popCount'.


The fifth patch (for base) is what prompted me to get around to sending
this proposal. It lets us de-orphan the Show Integer instance.


Any opinions?


Suggested discussion deadline: 12th October


Thanks
Ian


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

0003-Remove-the-Show-superclass-of-Num.patch (3K) Download Attachment
0001-Follow-the-removal-of-the-Show-superclass-of-Num.patch (1K) Download Attachment
0004-Remove-the-Eq-superclass-of-Num.patch (7K) Download Attachment
0001-Follow-the-removal-of-the-Eq-superclass-of-Num.patch (1K) Download Attachment
0005-De-orphan-the-Show-Integer-instance.patch (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Remove Show and Eq superclasses of Num

Ivan Lazar Miljenovic
On 16 September 2011 08:58, Ian Lynagh <[hidden email]> wrote:

>
> Hi all,
>
> I would like to propose that we remove the Show and Eq superclasses from
> Num, i.e. change
>    class  (Eq a, Show a) => Num a  where
>        [...]
> to
>    class  Num a  where
>        [...]

+1

--
Ivan Lazar Miljenovic
[hidden email]
IvanMiljenovic.wordpress.com

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Remove Show and Eq superclasses of Num

Edward Kmett
In reply to this post by Ian Lynagh
+1 from me.

The primary concern is of course that this means loss of compatibility with the current Haskell Report.

foo :: Num a => a -> String
foo = show

would cease to type check.

-Edward

Sent from my iPad

On Sep 15, 2011, at 6:58 PM, Ian Lynagh <[hidden email]> wrote:

>
> Hi all,
>
> I would like to propose that we remove the Show and Eq superclasses from
> Num, i.e. change
>    class  (Eq a, Show a) => Num a  where
>        [...]
> to
>    class  Num a  where
>        [...]
>
>
> The first 2 attached patches (for base and ghc respectively) remove the
> Show constraint. I'm not aware of any justification for why this
> superclass makes sense.
>
>
> The next 2 patches (for base and unix respectively) remove the Eq
> constraint. Here's there's some justification in the superclass, as it
> makes
>    f 5 = ...
> work for any Num type, rather than also needing an Eq constraint, but
> personally I would be in favour of removing this superclass too.
> Noteworthy is that Bits now needs an Eq superclass for the default
> methods for 'testBit' and 'popCount'.
>
>
> The fifth patch (for base) is what prompted me to get around to sending
> this proposal. It lets us de-orphan the Show Integer instance.
>
>
> Any opinions?
>
>
> Suggested discussion deadline: 12th October
>
>
> Thanks
> Ian
>
> <0003-Remove-the-Show-superclass-of-Num.patch>
> <0001-Follow-the-removal-of-the-Show-superclass-of-Num.patch>
> <0004-Remove-the-Eq-superclass-of-Num.patch>
> <0001-Follow-the-removal-of-the-Eq-superclass-of-Num.patch>
> <0005-De-orphan-the-Show-Integer-instance.patch>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Proposal: Remove Show and Eq superclasses of Num

Ross Paterson-2
In reply to this post by Ian Lynagh
Ian Lynagh writes:
> I would like to propose that we remove the Show and Eq superclasses from
> Num, i.e. change
>     class  (Eq a, Show a) => Num a  where
>         [...]
> to
>     class  Num a  where
>         [...]

This will break client code, but will not fix other defects of Num,
namely the inclusion of abs/signum, and tying (*) to (+).  I think the
right approach is to refactor the numeric classes along algebraic lines:

http://hackage.haskell.org/package/yap

Leave Num with its broken interface for backward compatibility (for
clients), but provide a clean Ring superclass for new code.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Remove Show and Eq superclasses of Num

Ian Lynagh
On Fri, Sep 16, 2011 at 12:47:18AM +0100, Paterson, Ross wrote:

> Ian Lynagh writes:
> > I would like to propose that we remove the Show and Eq superclasses from
> > Num, i.e. change
> >     class  (Eq a, Show a) => Num a  where
> >         [...]
> > to
> >     class  Num a  where
> >         [...]
>
> This will break client code, but will not fix other defects of Num,

It doesn't solve everything, but I hope we can agree it is an
incremental step in the right direction. I don't think a revolutionary
change fixing all the issues is feasible. This particular blemish was
already being described as "largely historical" more than a decade ago:
    http://www.haskell.org/pipermail/haskell/2000-October/006147.html


Thanks
Ian


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Remove Show and Eq superclasses of Num

sclv
On Sep 15, 2011, at 9:41 PM, Ian Lynagh wrote:

It doesn't solve everything, but I hope we can agree it is an
incremental step in the right direction. I don't think a revolutionary
change fixing all the issues is feasible. This particular blemish was
already being described as "largely historical" more than a decade ago:
   http://www.haskell.org/pipermail/haskell/2000-October/006147.html


+1

This is relatively painless and makes things much better. We should do it sooner rather than later.

--S 

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Remove Show and Eq superclasses of Num

Johan Tibell-2
In reply to this post by Ian Lynagh

+1

On Sep 16, 2011 10:42 AM, "Ian Lynagh" <[hidden email]> wrote:
> On Fri, Sep 16, 2011 at 12:47:18AM +0100, Paterson, Ross wrote:
>> Ian Lynagh writes:
>> > I would like to propose that we remove the Show and Eq superclasses from
>> > Num, i.e. change
>> > class (Eq a, Show a) => Num a where
>> > [...]
>> > to
>> > class Num a where
>> > [...]
>>
>> This will break client code, but will not fix other defects of Num,
>
> It doesn't solve everything, but I hope we can agree it is an
> incremental step in the right direction. I don't think a revolutionary
> change fixing all the issues is feasible. This particular blemish was
> already being described as "largely historical" more than a decade ago:
> http://www.haskell.org/pipermail/haskell/2000-October/006147.html
>
>
> Thanks
> Ian
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Remove Show and Eq superclasses of Num

Balazs Komuves
In reply to this post by Ian Lynagh

+1
I fully agree that this small incremental change is good step in this case.
Balazs Komuves


I would like to propose that we remove the Show and Eq superclasses from
Num, i.e. change
   class  (Eq a, Show a) => Num a  where
       [...]
to
   class  Num a  where
       [...]


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Remove Show and Eq superclasses of Num

Herbert Valerio Riedel
In reply to this post by Ian Lynagh
On Fri, 2011-09-16 at 02:41 +0100, Ian Lynagh wrote:

> > > I would like to propose that we remove the Show and Eq superclasses from
> > > Num, i.e. change
> > >     class  (Eq a, Show a) => Num a  where
> > >         [...]
> > > to
> > >     class  Num a  where
> > >         [...]
> >
> > This will break client code, but will not fix other defects of Num,
>
> It doesn't solve everything, but I hope we can agree it is an
> incremental step in the right direction. I don't think a revolutionary
> change fixing all the issues is feasible. This particular blemish was
> already being described as "largely historical" more than a decade ago:
>     http://www.haskell.org/pipermail/haskell/2000-October/006147.html

+1



Just as a side note: I also dislike that the Data.Bits.Bits type-class
has Num as its superclass; If I need something to be an instance of the
Bits class for the bit-ops, I don't usually want to be forced to provide
multiplication and addition operations as well...


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Num superclass of Bits (Was: Proposal: Remove Show and Eq superclasses of Num)

Henning Thielemann

On Fri, 16 Sep 2011, Herbert Valerio Riedel wrote:

> Just as a side note: I also dislike that the Data.Bits.Bits type-class
> has Num as its superclass; If I need something to be an instance of the
> Bits class for the bit-ops, I don't usually want to be forced to provide
> multiplication and addition operations as well...

Me too. For instance when working with flag sets like in [1], addition,
multiplication, absolute value, number literals make no sense.

[1] http://hackage.haskell.org/package/enumset

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Remove Show and Eq superclasses of Num

Daniel Díaz Casanueva
In reply to this post by Herbert Valerio Riedel
I found this proposal interesting. Indeed, as far as I can remember, almost every instance I did in the Num class forced me to do a couple of instances more (Eq and Show) that I have never thought to do. Sometimes, even there was no way to do them (in a reasonable way).
 
Well, this is just another opinion.
 
Sincerely,
Daniel Díaz.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Remove Show and Eq superclasses of Num

Brent Yorgey-2
In reply to this post by Ian Lynagh
On Thu, Sep 15, 2011 at 11:58:21PM +0100, Ian Lynagh wrote:

>
> Hi all,
>
> I would like to propose that we remove the Show and Eq superclasses from
> Num, i.e. change
>     class  (Eq a, Show a) => Num a  where
>         [...]
> to
>     class  Num a  where
>         [...]

+1 to all five patches.

-Brent

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Proposal: Remove Show and Eq superclasses of Num

Ross Paterson-2
In reply to this post by Ian Lynagh
Ian Lynagh writes:
> It doesn't solve everything, but I hope we can agree it is an
> incremental step in the right direction. I don't think a revolutionary
> change fixing all the issues is feasible. This particular blemish was
> already being described as "largely historical" more than a decade ago:
>     http://www.haskell.org/pipermail/haskell/2000-October/006147.html

All these blemishes have been described as historical for a long time.
But I'm suggesting that we address them by going in a different direction.

Under this proposal the 7 numeric classes lose the Show superclass,
and Num, Fractional and Floating lose the Eq superclass.  That breaks
compatibility with Haskell 98, and will break functions that have
numeric classes in their signatures and use equality or show in their
implementations (e.g. the patches need to change the signatures of
27 functions in ghc and the core libs).  If we're considering that,
we ought also to consider alternative trade-offs between interface
improvement and breakage.

The alternative approach is to refactor the numeric classes internally
(as in the yap package).  That will break packages too, probably more,
but that will leave us with much more sensible and useful classes.
And the breakage falls on different users:
- If we remove superclasses of Num, it falls on (some) people who put
  numeric classes in their type signatures.
- If we refactor the numeric classes internally, it falls on those who
  define instances of numeric classes.  (I would argue that many of those
  instances are kludged today because of the flawed classes.) Those
  who merely use the numeric classes in type signatures or call their
  methods should be unaffected.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Remove Show and Eq superclasses of Num

Sebastian Fischer-2
On Sat, Sep 17, 2011 at 8:37 AM, Paterson, Ross <[hidden email]> wrote:
> Those
>  who merely use the numeric classes in type signatures or call their
>  methods should be unaffected.

Then Eq and Show must be superclasses of Num forever, which is the
wart Ian wants to address. I think that these superclasses should be
removed *and* the classes should be restructured along the lines of
yap. I don't care in which order, so +1 from me.

Sebastian

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Num superclass of Bits (Was: Proposal: Remove Show and Eq superclasses of Num)

John Meacham
In reply to this post by Henning Thielemann
I also really dislike that superclass of bits, there is no need for it.

    John

On Fri, Sep 16, 2011 at 5:12 AM, Henning Thielemann
<[hidden email]> wrote:

>
> On Fri, 16 Sep 2011, Herbert Valerio Riedel wrote:
>
>> Just as a side note: I also dislike that the Data.Bits.Bits type-class
>> has Num as its superclass; If I need something to be an instance of the
>> Bits class for the bit-ops, I don't usually want to be forced to provide
>> multiplication and addition operations as well...
>
> Me too. For instance when working with flag sets like in [1], addition,
> multiplication, absolute value, number literals make no sense.
>
> [1] http://hackage.haskell.org/package/enumset
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Num superclass of Bits (Was: Proposal: Remove Show and Eq superclasses of Num)

Edward Kmett
That and it prevents the obvious instance for Bool.

On Fri, Sep 16, 2011 at 8:51 PM, John Meacham <[hidden email]> wrote:
I also really dislike that superclass of bits, there is no need for it.

   John

On Fri, Sep 16, 2011 at 5:12 AM, Henning Thielemann
<[hidden email]> wrote:
>
> On Fri, 16 Sep 2011, Herbert Valerio Riedel wrote:
>
>> Just as a side note: I also dislike that the Data.Bits.Bits type-class
>> has Num as its superclass; If I need something to be an instance of the
>> Bits class for the bit-ops, I don't usually want to be forced to provide
>> multiplication and addition operations as well...
>
> Me too. For instance when working with flag sets like in [1], addition,
> multiplication, absolute value, number literals make no sense.
>
> [1] http://hackage.haskell.org/package/enumset
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Remove Show and Eq superclasses of Num

John Meacham
In reply to this post by Ross Paterson-2
The good thing about the incremental step of removing the superclasses
as an intermediate step is that it lets you write forwards and
backwards compatible code. just include Eq a,Num a in your type
signatures, the haskell 98 compiler won't complain and you can still
be compatibile with the new classes.

   John

On Fri, Sep 16, 2011 at 4:37 PM, Paterson, Ross <[hidden email]> wrote:

> Ian Lynagh writes:
>> It doesn't solve everything, but I hope we can agree it is an
>> incremental step in the right direction. I don't think a revolutionary
>> change fixing all the issues is feasible. This particular blemish was
>> already being described as "largely historical" more than a decade ago:
>>     http://www.haskell.org/pipermail/haskell/2000-October/006147.html
>
> All these blemishes have been described as historical for a long time.
> But I'm suggesting that we address them by going in a different direction.
>
> Under this proposal the 7 numeric classes lose the Show superclass,
> and Num, Fractional and Floating lose the Eq superclass.  That breaks
> compatibility with Haskell 98, and will break functions that have
> numeric classes in their signatures and use equality or show in their
> implementations (e.g. the patches need to change the signatures of
> 27 functions in ghc and the core libs).  If we're considering that,
> we ought also to consider alternative trade-offs between interface
> improvement and breakage.
>
> The alternative approach is to refactor the numeric classes internally
> (as in the yap package).  That will break packages too, probably more,
> but that will leave us with much more sensible and useful classes.
> And the breakage falls on different users:
> - If we remove superclasses of Num, it falls on (some) people who put
>  numeric classes in their type signatures.
> - If we refactor the numeric classes internally, it falls on those who
>  define instances of numeric classes.  (I would argue that many of those
>  instances are kludged today because of the flawed classes.) Those
>  who merely use the numeric classes in type signatures or call their
>  methods should be unaffected.
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Remove Show and Eq superclasses of Num

Malcolm Wallace-2
In reply to this post by Ian Lynagh
> The first 2 attached patches (for base and ghc respectively) remove the
> Show constraint. I'm not aware of any justification for why this
> superclass makes sense.

I'm strongly in favour of removing the Show constraint.

> The next 2 patches (for base and unix respectively) remove the Eq
> constraint. Here's there's some justification in the superclass, as it
> makes
>    f 5 = ...
> work for any Num type, rather than also needing an Eq constraint,

I am undecided whether removing the Eq constraint is a good thing or not.  In principle, yes, it makes perfect sense.  But in practice, the example you give of pattern-matching a literal now requiring an Eq context, smells slightly wrong to me.  Pattern-matching on any other kind of constructor does not require an Eq context: it feels like some of the magic of literal numbers (I know they aren't really literals, they just appear that way) is wearing off and the underlying reality (where they are not constructors at all) is becoming visible.

Regards,
    Malcolm

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Remove Show and Eq superclasses of Num

Ganesh Sittampalam
In reply to this post by Ian Lynagh

On 15/09/2011 23:58, Ian Lynagh wrote:

>
>
> The next 2 patches (for base and unix respectively) remove the Eq
> constraint. Here's there's some justification in the superclass, as it
> makes
>     f 5 = ...
> work for any Num type, rather than also needing an Eq constraint, but
> personally I would be in favour of removing this superclass too.
> Noteworthy is that Bits now needs an Eq superclass for the default
> methods for 'testBit' and 'popCount'.

I have a vague recollection that there are some generic implementations
of sqrt that rely on equality tests with 0. I can't spot any in the
Haskell library source, though.

Otherwise +1; one significant benefit of this change would be for EDSLs
which currently have to have broken Eq instances to implement Num.

Cheers,

Ganesh

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Remove Show and Eq superclasses of Num

Gábor Lehel
In reply to this post by Ian Lynagh
On Fri, Sep 16, 2011 at 12:58 AM, Ian Lynagh <[hidden email]> wrote:

>
> Hi all,
>
> I would like to propose that we remove the Show and Eq superclasses from
> Num, i.e. change
>    class  (Eq a, Show a) => Num a  where
>        [...]
> to
>    class  Num a  where
>        [...]
>
>
> The first 2 attached patches (for base and ghc respectively) remove the
> Show constraint. I'm not aware of any justification for why this
> superclass makes sense.
>
>
> The next 2 patches (for base and unix respectively) remove the Eq
> constraint. Here's there's some justification in the superclass, as it
> makes
>    f 5 = ...
> work for any Num type, rather than also needing an Eq constraint, but
> personally I would be in favour of removing this superclass too.
> Noteworthy is that Bits now needs an Eq superclass for the default
> methods for 'testBit' and 'popCount'.
>
>
> The fifth patch (for base) is what prompted me to get around to sending
> this proposal. It lets us de-orphan the Show Integer instance.
>
>
> Any opinions?
>
>
> Suggested discussion deadline: 12th October
>
>
> Thanks
> Ian

As a thought experiment, with the ConstraintKinds extension coming up,
what would it take to make this change fully backwards compatible?

With ConstraintKinds, we could write:

type Num a = (Show a, Eq a, Num a) -- ???

...okay, maybe not.

We could define separate Nums in separate modules, though:

module OldNum where
import qualified NewNum
type Num a = (Show a, Eq a, NewNum.Num a)

and have the Num exported from the Prelude be the one from OldNum.
That way, code relying on a Num context also implying Show and Eq
doesn't break. But instance declarations break instead, which is
probably worse.

If we also have
http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
more specifically, the "Multi-headed instance declarations" part from
the end, then writing

instance OldNum.Num Foo where
    (+) = ...
    ... etc. ...

would distribute the method definitions for OldNum.Num to Eq, Show,
and NewNum.Num. That gets us tantalizingly close. The problem is that
(a) instances for Num in existing code won't include definitions for
Eq and Show, and (b) separate instances for Eq and Show will be in
scope. The naive implementation of the feature will just emit
instances for Eq and Show with undefined method bodies, resulting
forthwith in a duplicate instance conflict.

One straightforward solution would be to refrain from emitting an
instance if (a) an instance for that class (for the given type) is
already in scope, and (b) the instance declaration for the
constraint-tuple doesn't include any definitions pertaining to that
class. Perhaps accompanied by a warning. I'm not sure if that's
palatable, though. It would mainly be problematic with classes for
which it's reasonable to declare instances with an empty body (maybe
because it's using the new Generics feature, for example): the user
might be expecting to declare a new instance and be surprised to find
that an existing one is being used instead, especially if the
'existing one' is introduced later, somewhere higher up the import
hierarchy. Warnings would at least let her know it's happening,
though.

Is there any other way to do it?

In any case, the question is whether a solution allowing full
backwards compatibility is possible and whether it has any likelihood
of being implemented in GHC in the near future. (Half of it is already
there, with ConstraintKinds.) If it's straight-up impossible or is
unlikely to be implemented, I see no reason not to +1 this proposal.
Otherwise, it might make sense to wait. If it's been more than a
decade, after all, what's another year?

--
Work is punishment for failing to procrastinate effectively.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
123
Loading...