add map back to Functor

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

add map back to Functor

Carter Schonwald
harkening back to the old Haskell 1.5 days, Lets have map back in functor. it "F"-  strange to not have our lovely maps be functorial by default.

I think it would be a genuine boon for old and new haskellers alike, and those who disagree with this change already use alt-preludes for pedagogy reasons anyways

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: add map back to Functor

Edward Kmett-2
The real problem with this sketch of a proposal is the lack of a nice migration plan.

If it is top level and just calls fmap, then the distinction requires random rote memorization of which one you can define.

On the other hand, say you put it in Functor today as an extra member. Currently everybody has definitions in terms of `fmap`, so you'd need to make the two definitions mutual. This would mean enlarging the dictionaries for one of the most common structures in Haskell for a rather far flung removal that breaks everyone.

If we had a way (say a pragma or other syntactic form) to say that fmap and map were somehow the 'same name' or something and so that defining one was the same as defining the other, so that this tax didn't exist, I could see how we might get there.

That sort of "magic" might be useful for making migration plans to get sequenceA to be sequence and mapM and traverse without requiring folks to memorize which one is in the class and which is a top level definition.

Without something like that, I'd remain somewhat inclined against concocting a complicated migration plan to save one letter.

-Edward

On Fri, Feb 8, 2019 at 12:07 PM Carter Schonwald <[hidden email]> wrote:
harkening back to the old Haskell 1.5 days, Lets have map back in functor. it "F"-  strange to not have our lovely maps be functorial by default.

I think it would be a genuine boon for old and new haskellers alike, and those who disagree with this change already use alt-preludes for pedagogy reasons anyways
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: add map back to Functor

Carter Schonwald
You make a good point, we should cook up this desired magic pragma!

Could you sketch out 1-2 examples of what you’d want this pragma to do?

Something like 
{-# method_synonym_of fmap map #-} 
?
This would sort of be like a sort of duplicate record field for how names are mapped to definitions? 
This example would be “fmap is an alias of map”


On Fri, Feb 8, 2019 at 1:46 PM Edward Kmett <[hidden email]> wrote:
The real problem with this sketch of a proposal is the lack of a nice migration plan.

If it is top level and just calls fmap, then the distinction requires random rote memorization of which one you can define.

On the other hand, say you put it in Functor today as an extra member. Currently everybody has definitions in terms of `fmap`, so you'd need to make the two definitions mutual. This would mean enlarging the dictionaries for one of the most common structures in Haskell for a rather far flung removal that breaks everyone.

If we had a way (say a pragma or other syntactic form) to say that fmap and map were somehow the 'same name' or something and so that defining one was the same as defining the other, so that this tax didn't exist, I could see how we might get there.

That sort of "magic" might be useful for making migration plans to get sequenceA to be sequence and mapM and traverse without requiring folks to memorize which one is in the class and which is a top level definition.

Without something like that, I'd remain somewhat inclined against concocting a complicated migration plan to save one letter.

-Edward

On Fri, Feb 8, 2019 at 12:07 PM Carter Schonwald <[hidden email]> wrote:
harkening back to the old Haskell 1.5 days, Lets have map back in functor. it "F"-  strange to not have our lovely maps be functorial by default.

I think it would be a genuine boon for old and new haskellers alike, and those who disagree with this change already use alt-preludes for pedagogy reasons anyways
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: add map back to Functor

Bardur Arantsson-2
In reply to this post by Edward Kmett-2
On 08/02/2019 19.45, Edward Kmett wrote:
> If we had a way (say a pragma or other syntactic form) to say that fmap
> and map were somehow the 'same name' or something and so that defining
> one was the same as defining the other, so that this tax didn't exist, I
> could see how we might get there.
>

+1 for "the way"

Most of these 'migrations' which are mostly syntactic should be
automatable and really should be *automated* via some sort of tool
support. I still haven't experienced a language where this sort of thing
"just works", but IMO gofix and scalafix have sort of the right idea.

(In Haskell we have the luxury of 'only' having to guarantee source
compatibility.)

If people are worried about having to add CPP sections, then I would
submit it's very possible to convert diffs (between pre-fix to post-fix)
to CPP. That, or one can usually create a *-compat library which
contains the CPP and just use that as a dependency. Ugly, yes, but in
practical terms it seems to be quite simple.

Regards,

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: add map back to Functor

Elliot Cameron-2
Even with a tool to automate it I know many authors would be very disturbed by such a huge diff in their code. On larger teams with many active branches this kind of sweeping change is quite difficult to maneuver.

On Fri, Feb 8, 2019, 4:42 PM Bardur Arantsson <[hidden email] wrote:
On 08/02/2019 19.45, Edward Kmett wrote:
> If we had a way (say a pragma or other syntactic form) to say that fmap
> and map were somehow the 'same name' or something and so that defining
> one was the same as defining the other, so that this tax didn't exist, I
> could see how we might get there.
>

+1 for "the way"

Most of these 'migrations' which are mostly syntactic should be
automatable and really should be *automated* via some sort of tool
support. I still haven't experienced a language where this sort of thing
"just works", but IMO gofix and scalafix have sort of the right idea.

(In Haskell we have the luxury of 'only' having to guarantee source
compatibility.)

If people are worried about having to add CPP sections, then I would
submit it's very possible to convert diffs (between pre-fix to post-fix)
to CPP. That, or one can usually create a *-compat library which
contains the CPP and just use that as a dependency. Ugly, yes, but in
practical terms it seems to be quite simple.

Regards,

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: add map back to Functor

Carter Schonwald
No... the point of such an extension would be that no code that already works would need to change.  Except to the extent 


If I’m not understanding your misapprehension,
Could you lay out a specific micro example ?

On Sat, Feb 9, 2019 at 8:07 AM Elliot Cameron <[hidden email]> wrote:
Even with a tool to automate it I know many authors would be very disturbed by such a huge diff in their code. On larger teams with many active branches this kind of sweeping change is quite difficult to maneuver.

On Fri, Feb 8, 2019, 4:42 PM Bardur Arantsson <[hidden email] wrote:
On 08/02/2019 19.45, Edward Kmett wrote:
> If we had a way (say a pragma or other syntactic form) to say that fmap
> and map were somehow the 'same name' or something and so that defining
> one was the same as defining the other, so that this tax didn't exist, I
> could see how we might get there.
>

+1 for "the way"

Most of these 'migrations' which are mostly syntactic should be
automatable and really should be *automated* via some sort of tool
support. I still haven't experienced a language where this sort of thing
"just works", but IMO gofix and scalafix have sort of the right idea.

(In Haskell we have the luxury of 'only' having to guarantee source
compatibility.)

If people are worried about having to add CPP sections, then I would
submit it's very possible to convert diffs (between pre-fix to post-fix)
to CPP. That, or one can usually create a *-compat library which
contains the CPP and just use that as a dependency. Ugly, yes, but in
practical terms it seems to be quite simple.

Regards,

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: add map back to Functor

Carter Schonwald
All good :) , complicated stuff is hard to communicate.  I and likely others always benefit from more practice and folks comfortably asking questions spurred by ambiguity 

By migration in this context I think we all mean / desire a way to change a name / definition in such a way that the new name / interface works,  but also that all previous code still works, as well as code that’s a combination of both old and new also works.  

Such a mechanism or set of such tools (vaguely described as they are here ), is what I mean. 

So  we mean migration of meaning or underlying language spec, while not breaking perfectly great code 

On Sat, Feb 9, 2019 at 3:19 PM Elliot Cameron <[hidden email]> wrote:
In that case I must have misunderstood what the automatic migration would be. 

On Sat, Feb 9, 2019, 2:56 PM Carter Schonwald <[hidden email] wrote:
No... the point of such an extension would be that no code that already works would need to change.  Except to the extent 


If I’m not understanding your misapprehension,
Could you lay out a specific micro example ?

On Sat, Feb 9, 2019 at 8:07 AM Elliot Cameron <[hidden email]> wrote:
Even with a tool to automate it I know many authors would be very disturbed by such a huge diff in their code. On larger teams with many active branches this kind of sweeping change is quite difficult to maneuver.

On Fri, Feb 8, 2019, 4:42 PM Bardur Arantsson <[hidden email] wrote:
On 08/02/2019 19.45, Edward Kmett wrote:
> If we had a way (say a pragma or other syntactic form) to say that fmap
> and map were somehow the 'same name' or something and so that defining
> one was the same as defining the other, so that this tax didn't exist, I
> could see how we might get there.
>

+1 for "the way"

Most of these 'migrations' which are mostly syntactic should be
automatable and really should be *automated* via some sort of tool
support. I still haven't experienced a language where this sort of thing
"just works", but IMO gofix and scalafix have sort of the right idea.

(In Haskell we have the luxury of 'only' having to guarantee source
compatibility.)

If people are worried about having to add CPP sections, then I would
submit it's very possible to convert diffs (between pre-fix to post-fix)
to CPP. That, or one can usually create a *-compat library which
contains the CPP and just use that as a dependency. Ugly, yes, but in
practical terms it seems to be quite simple.

Regards,

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: add map back to Functor

amindfv
In reply to this post by Carter Schonwald


> El 8 feb 2019, a las 12:06 PM, Carter Schonwald <[hidden email]> escribió:
>
> harkening back to the old Haskell 1.5 days, Lets have map back in functor. it "F"-  strange to not have our lovely maps be functorial by default.
>
> I think it would be a genuine boon for old and new haskellers alike, and those who disagree with this change already use alt-preludes for pedagogy reasons anyways

I'm personally -1 on this even if we had a nice migration plan. (Even though I'm not someone who uses an alternative prelude!). "map" is a simple, helpful function. "fmap" is a nice generalized version. It's not costly in readability or typing to keep them separate.

Also, nearly every module I've written in Haskell has used "map," under the assumption it meant one thing, and changing it to mean something else (even if only generalized) will have more implications than I can go through and inspect. This is similar to how generalizing "length" in the BBP indirectly caused hard-to-track-down bugs.

Lastly, I don't think "pedagogy" can be entirely relegated to "use an alternative prelude". If when I was first evaluating _whether_ to use Haskell I had been told to use "-fno-implicit-prelude" and "import FakePrelude", I'd chafe at essentially being told "pay no attention to the man behind the curtain." If I'd been told that if I wanted to (+1) every element of a list I had to learn a small bit of category theory, I'd have thought "wow, it really is just a language for mathematicians" and likely thought the language wasn't for me. In my view this proposal will make Haskell more intimidating, when we should be trying as much as we can to make it less!

Tom


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: add map back to Functor

Mario Blažević-3
In reply to this post by Edward Kmett-2
On 2019-02-08 1:45 p.m., Edward Kmett wrote:
>
> That sort of "magic" might be useful for making migration plans to get
> sequenceA to be sequence and mapM and traverse without requiring folks
> to memorize which one is in the class and which is a top level definition.

A similar sort of magic could be used for MonadOfNoReturn: we want to
end up with a `return = pure` definition, not a method of any class,
while all the existing code still compiles. Or is that migration plan
already fully covered by existing magic tricks?


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: add map back to Functor

Ryan Reich
In reply to this post by Carter Schonwald
This pragma needs to have a type inference guarantee that the old signature `map :: (a -> b) -> [a] -> [b]` is applied even after subsituting `fmap :: (Functor f) => (a -> b) -> f a -> f b`.  There must be approximately one zillion ad-hoc functions out there written without type signatures that implicitly depend on inferring a list.

On Fri, Feb 8, 2019 at 11:33 AM Carter Schonwald <[hidden email]> wrote:
You make a good point, we should cook up this desired magic pragma!

Could you sketch out 1-2 examples of what you’d want this pragma to do?

Something like 
{-# method_synonym_of fmap map #-} 
?
This would sort of be like a sort of duplicate record field for how names are mapped to definitions? 
This example would be “fmap is an alias of map”


On Fri, Feb 8, 2019 at 1:46 PM Edward Kmett <[hidden email]> wrote:
The real problem with this sketch of a proposal is the lack of a nice migration plan.

If it is top level and just calls fmap, then the distinction requires random rote memorization of which one you can define.

On the other hand, say you put it in Functor today as an extra member. Currently everybody has definitions in terms of `fmap`, so you'd need to make the two definitions mutual. This would mean enlarging the dictionaries for one of the most common structures in Haskell for a rather far flung removal that breaks everyone.

If we had a way (say a pragma or other syntactic form) to say that fmap and map were somehow the 'same name' or something and so that defining one was the same as defining the other, so that this tax didn't exist, I could see how we might get there.

That sort of "magic" might be useful for making migration plans to get sequenceA to be sequence and mapM and traverse without requiring folks to memorize which one is in the class and which is a top level definition.

Without something like that, I'd remain somewhat inclined against concocting a complicated migration plan to save one letter.

-Edward

On Fri, Feb 8, 2019 at 12:07 PM Carter Schonwald <[hidden email]> wrote:
harkening back to the old Haskell 1.5 days, Lets have map back in functor. it "F"-  strange to not have our lovely maps be functorial by default.

I think it would be a genuine boon for old and new haskellers alike, and those who disagree with this change already use alt-preludes for pedagogy reasons anyways
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: add map back to Functor

Ryan Reich
...which is a problem, because you can't distinguish code that was written (either before or after the pragma is introduced) with the assumption of a list in mind from code (written after the pragma is introduced) that intends to use the generalized type signature.  This is different from the situation created by `instance Functor [] where {fmap = map}`, which introduces a specialization of `fmap` rather than a generalization of `map`.

On Sat, Feb 9, 2019 at 8:15 PM Ryan Reich <[hidden email]> wrote:
This pragma needs to have a type inference guarantee that the old signature `map :: (a -> b) -> [a] -> [b]` is applied even after subsituting `fmap :: (Functor f) => (a -> b) -> f a -> f b`.  There must be approximately one zillion ad-hoc functions out there written without type signatures that implicitly depend on inferring a list.

On Fri, Feb 8, 2019 at 11:33 AM Carter Schonwald <[hidden email]> wrote:
You make a good point, we should cook up this desired magic pragma!

Could you sketch out 1-2 examples of what you’d want this pragma to do?

Something like 
{-# method_synonym_of fmap map #-} 
?
This would sort of be like a sort of duplicate record field for how names are mapped to definitions? 
This example would be “fmap is an alias of map”


On Fri, Feb 8, 2019 at 1:46 PM Edward Kmett <[hidden email]> wrote:
The real problem with this sketch of a proposal is the lack of a nice migration plan.

If it is top level and just calls fmap, then the distinction requires random rote memorization of which one you can define.

On the other hand, say you put it in Functor today as an extra member. Currently everybody has definitions in terms of `fmap`, so you'd need to make the two definitions mutual. This would mean enlarging the dictionaries for one of the most common structures in Haskell for a rather far flung removal that breaks everyone.

If we had a way (say a pragma or other syntactic form) to say that fmap and map were somehow the 'same name' or something and so that defining one was the same as defining the other, so that this tax didn't exist, I could see how we might get there.

That sort of "magic" might be useful for making migration plans to get sequenceA to be sequence and mapM and traverse without requiring folks to memorize which one is in the class and which is a top level definition.

Without something like that, I'd remain somewhat inclined against concocting a complicated migration plan to save one letter.

-Edward

On Fri, Feb 8, 2019 at 12:07 PM Carter Schonwald <[hidden email]> wrote:
harkening back to the old Haskell 1.5 days, Lets have map back in functor. it "F"-  strange to not have our lovely maps be functorial by default.

I think it would be a genuine boon for old and new haskellers alike, and those who disagree with this change already use alt-preludes for pedagogy reasons anyways
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: add map back to Functor

Carter Schonwald
no, map should have the more general type :) 

On Sat, Feb 9, 2019 at 11:28 PM Ryan Reich <[hidden email]> wrote:
...which is a problem, because you can't distinguish code that was written (either before or after the pragma is introduced) with the assumption of a list in mind from code (written after the pragma is introduced) that intends to use the generalized type signature.  This is different from the situation created by `instance Functor [] where {fmap = map}`, which introduces a specialization of `fmap` rather than a generalization of `map`.

On Sat, Feb 9, 2019 at 8:15 PM Ryan Reich <[hidden email]> wrote:
This pragma needs to have a type inference guarantee that the old signature `map :: (a -> b) -> [a] -> [b]` is applied even after subsituting `fmap :: (Functor f) => (a -> b) -> f a -> f b`.  There must be approximately one zillion ad-hoc functions out there written without type signatures that implicitly depend on inferring a list.

On Fri, Feb 8, 2019 at 11:33 AM Carter Schonwald <[hidden email]> wrote:
You make a good point, we should cook up this desired magic pragma!

Could you sketch out 1-2 examples of what you’d want this pragma to do?

Something like 
{-# method_synonym_of fmap map #-} 
?
This would sort of be like a sort of duplicate record field for how names are mapped to definitions? 
This example would be “fmap is an alias of map”


On Fri, Feb 8, 2019 at 1:46 PM Edward Kmett <[hidden email]> wrote:
The real problem with this sketch of a proposal is the lack of a nice migration plan.

If it is top level and just calls fmap, then the distinction requires random rote memorization of which one you can define.

On the other hand, say you put it in Functor today as an extra member. Currently everybody has definitions in terms of `fmap`, so you'd need to make the two definitions mutual. This would mean enlarging the dictionaries for one of the most common structures in Haskell for a rather far flung removal that breaks everyone.

If we had a way (say a pragma or other syntactic form) to say that fmap and map were somehow the 'same name' or something and so that defining one was the same as defining the other, so that this tax didn't exist, I could see how we might get there.

That sort of "magic" might be useful for making migration plans to get sequenceA to be sequence and mapM and traverse without requiring folks to memorize which one is in the class and which is a top level definition.

Without something like that, I'd remain somewhat inclined against concocting a complicated migration plan to save one letter.

-Edward

On Fri, Feb 8, 2019 at 12:07 PM Carter Schonwald <[hidden email]> wrote:
harkening back to the old Haskell 1.5 days, Lets have map back in functor. it "F"-  strange to not have our lovely maps be functorial by default.

I think it would be a genuine boon for old and new haskellers alike, and those who disagree with this change already use alt-preludes for pedagogy reasons anyways
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: add map back to Functor

Carter Schonwald
and the alluded extension / pragma idea would be for equi typed names,not for anyting fancy about type subsumption

On Mon, Feb 11, 2019 at 1:14 PM Carter Schonwald <[hidden email]> wrote:
no, map should have the more general type :) 

On Sat, Feb 9, 2019 at 11:28 PM Ryan Reich <[hidden email]> wrote:
...which is a problem, because you can't distinguish code that was written (either before or after the pragma is introduced) with the assumption of a list in mind from code (written after the pragma is introduced) that intends to use the generalized type signature.  This is different from the situation created by `instance Functor [] where {fmap = map}`, which introduces a specialization of `fmap` rather than a generalization of `map`.

On Sat, Feb 9, 2019 at 8:15 PM Ryan Reich <[hidden email]> wrote:
This pragma needs to have a type inference guarantee that the old signature `map :: (a -> b) -> [a] -> [b]` is applied even after subsituting `fmap :: (Functor f) => (a -> b) -> f a -> f b`.  There must be approximately one zillion ad-hoc functions out there written without type signatures that implicitly depend on inferring a list.

On Fri, Feb 8, 2019 at 11:33 AM Carter Schonwald <[hidden email]> wrote:
You make a good point, we should cook up this desired magic pragma!

Could you sketch out 1-2 examples of what you’d want this pragma to do?

Something like 
{-# method_synonym_of fmap map #-} 
?
This would sort of be like a sort of duplicate record field for how names are mapped to definitions? 
This example would be “fmap is an alias of map”


On Fri, Feb 8, 2019 at 1:46 PM Edward Kmett <[hidden email]> wrote:
The real problem with this sketch of a proposal is the lack of a nice migration plan.

If it is top level and just calls fmap, then the distinction requires random rote memorization of which one you can define.

On the other hand, say you put it in Functor today as an extra member. Currently everybody has definitions in terms of `fmap`, so you'd need to make the two definitions mutual. This would mean enlarging the dictionaries for one of the most common structures in Haskell for a rather far flung removal that breaks everyone.

If we had a way (say a pragma or other syntactic form) to say that fmap and map were somehow the 'same name' or something and so that defining one was the same as defining the other, so that this tax didn't exist, I could see how we might get there.

That sort of "magic" might be useful for making migration plans to get sequenceA to be sequence and mapM and traverse without requiring folks to memorize which one is in the class and which is a top level definition.

Without something like that, I'd remain somewhat inclined against concocting a complicated migration plan to save one letter.

-Edward

On Fri, Feb 8, 2019 at 12:07 PM Carter Schonwald <[hidden email]> wrote:
harkening back to the old Haskell 1.5 days, Lets have map back in functor. it "F"-  strange to not have our lovely maps be functorial by default.

I think it would be a genuine boon for old and new haskellers alike, and those who disagree with this change already use alt-preludes for pedagogy reasons anyways
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries