Drastic Prelude changes imminent

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
129 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

Drastic Prelude changes imminent

Augustsson, Lennart

The next version (7.10) of GHC is slated to have a drastically changed Prelude.

This message is very late in the release process, but I would urge caution before changing.

 

The changes are (aptly) named the Burning Bridges Proposal (BBP).

Even though the work has been going on for a while, it seems that this

change is coming as a surprise to many people (including Simon Peyton

Jones).  In summary, it generalizes many list operation, e.g., foldr,

to be overloaded.

 

There is much to welcome in BBP, but changing the Prelude cannot be

done lightly since it really is like changing the language.

So I think it's really important for a large number of people to be able to

try out such changes before they come into effect, and to have time

to let the changes stabilize (you rarely get it right the first time).

 

I've discussed this with a number of people, including Simon PJ, and

we have concrete proposals.

 

Proposal 1:

*    Add a new pragma

        {-# LANGUAGE Prelude=AlternativePrelude #-}

      *   This is a new feature, but it is easy and low-risk to implement.

      *   Which Prelude you use really is a language choice; appropriate for a LANGUAGE pragma.

      *   Semantics is name-space only: import Prelude (); import AlternativePrelude

      *   No effect on desugaring or typing of built-in syntax (list comprehensions, do-notation etc).

*    Ship with both old and new prelude.

*    So now old and new behaviour are easy to achieve, in the module or in a .cabal file.

*    The question becomes "what is the default".

 

Proposal 2:

*    Make the default be the old rather than the new.

      *   Altering the default Prelude API should be done slowly, with lots of warning; because all users get it willy-nilly.

      *   Unlike AMP, the change is controversial (clearly).

      *   Easier to make changes to New Prelude if it isn't the default.

 

That's it.

 

 

 

 

Discussing the BBP proposal we also came up with a number of technical questions:

 

Q1

An alternative to Foldable would be

  class Enumerable t where

    toList :: t a -> [a]   -- Implementations should use 'build'

Is Foldable more general (or efficient) than a Enumerable class, plus fusion? 

 

Consider a new data type X a.  I write

     foldX :: (a -> b -> b) -> b -> X a -> b

     foldX = ...lots of code...

 

     toList :: X a -> [a]  {-# INLINE toList #-}

     toList x = build (\c n. foldX c n x)

           

So now toList is small and easy to inline.  Every good list consumer of a call to toList will turn into a call to foldX, which is what we want.

 

Q2

What are the criteria for being in Foldable?

For instance, why are 'sum', 'product' in Foldable, but not 'and', 'or'?

 

 

Q3

What's the relationship of Foldable to GHC.Exts.IsList?

Which also has toList, fromList, and does work with ByteString.

*  For example, could we use IsList instead of Foldable?

    Specifically, Foldable does not use its potential power to apply the type constructor t to different arguments.  (Unlike Traversable which does.)

        foldr :: IsList l => (Item l->b->b) -> b -> l -> b

 

 

  -- Lennart


This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.

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

Re: Drastic Prelude changes imminent

Erik Hesselink
On Tue, Jan 27, 2015 at 11:32 AM, Augustsson, Lennart
<[hidden email]> wrote:
> *    Add a new pragma
>         {-# LANGUAGE Prelude=AlternativePrelude #-}
>       *   Semantics is name-space only: import Prelude (); import
> AlternativePrelude

I don't have any opinion on the full proposal yet, but I usually use
"{-# LANGUAGE NoImplicitPrelude #-}" when using an alternate prelude.
Is there any different between that and "import Prelude ()"?

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

RE: Drastic Prelude changes imminent

Augustsson, Lennart
That's very different since it changes how desugaring works.
With NoImplicitPrelude desugaring uses unqualified names.  It's a rather fragile pragma.

-----Original Message-----
From: Erik Hesselink [mailto:[hidden email]]
Sent: 27 January 2015 11:11
To: Augustsson, Lennart
Cc: [hidden email]
Subject: Re: Drastic Prelude changes imminent

On Tue, Jan 27, 2015 at 11:32 AM, Augustsson, Lennart <[hidden email]> wrote:
> *    Add a new pragma
>         {-# LANGUAGE Prelude=AlternativePrelude #-}
>       *   Semantics is name-space only: import Prelude (); import
> AlternativePrelude

I don't have any opinion on the full proposal yet, but I usually use "{-# LANGUAGE NoImplicitPrelude #-}" when using an alternate prelude.
Is there any different between that and "import Prelude ()"?

Erik

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Drastic Prelude changes imminent

Erik Hesselink
What does that mean exactly? It sounds a bit like RebindableSyntax,
but I don't see it working that way. With NoImplicitPrelude, I can
locally define things like 'fromInteger' or '>>', but they are not
used in desugaring numeric literals or do notation.

Erik

On Tue, Jan 27, 2015 at 12:26 PM, Augustsson, Lennart
<[hidden email]> wrote:

> That's very different since it changes how desugaring works.
> With NoImplicitPrelude desugaring uses unqualified names.  It's a rather fragile pragma.
>
> -----Original Message-----
> From: Erik Hesselink [mailto:[hidden email]]
> Sent: 27 January 2015 11:11
> To: Augustsson, Lennart
> Cc: [hidden email]
> Subject: Re: Drastic Prelude changes imminent
>
> On Tue, Jan 27, 2015 at 11:32 AM, Augustsson, Lennart <[hidden email]> wrote:
>> *    Add a new pragma
>>         {-# LANGUAGE Prelude=AlternativePrelude #-}
>>       *   Semantics is name-space only: import Prelude (); import
>> AlternativePrelude
>
> I don't have any opinion on the full proposal yet, but I usually use "{-# LANGUAGE NoImplicitPrelude #-}" when using an alternate prelude.
> Is there any different between that and "import Prelude ()"?
>
> Erik
>
> This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
> http://www.standardchartered.com/en/incorporation-details.html
>
> Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx.
>
> Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Drastic Prelude changes imminent

Augustsson, Lennart
In reply to this post by Augustsson, Lennart

We’ve made a Wiki page with some relevant information, https://ghc.haskell.org/trac/ghc/wiki/BurningBridgesSlowly

 

 

From: Libraries [mailto:[hidden email]] On Behalf Of Augustsson, Lennart
Sent: 27 January 2015 10:33
To: [hidden email]
Subject: Drastic Prelude changes imminent

 

The next version (7.10) of GHC is slated to have a drastically changed Prelude.

This message is very late in the release process, but I would urge caution before changing.

 

The changes are (aptly) named the Burning Bridges Proposal (BBP).

Even though the work has been going on for a while, it seems that this

change is coming as a surprise to many people (including Simon Peyton

Jones).  In summary, it generalizes many list operation, e.g., foldr,

to be overloaded.

 

There is much to welcome in BBP, but changing the Prelude cannot be

done lightly since it really is like changing the language.

So I think it's really important for a large number of people to be able to

try out such changes before they come into effect, and to have time

to let the changes stabilize (you rarely get it right the first time).

 

I've discussed this with a number of people, including Simon PJ, and

we have concrete proposals.

 

Proposal 1:

*    Add a new pragma

        {-# LANGUAGE Prelude=AlternativePrelude #-}

      *   This is a new feature, but it is easy and low-risk to implement.

      *   Which Prelude you use really is a language choice; appropriate for a LANGUAGE pragma.

      *   Semantics is name-space only: import Prelude (); import AlternativePrelude

      *   No effect on desugaring or typing of built-in syntax (list comprehensions, do-notation etc).

*    Ship with both old and new prelude.

*    So now old and new behaviour are easy to achieve, in the module or in a .cabal file.

*    The question becomes "what is the default".

 

Proposal 2:

*    Make the default be the old rather than the new.

      *   Altering the default Prelude API should be done slowly, with lots of warning; because all users get it willy-nilly.

      *   Unlike AMP, the change is controversial (clearly).

      *   Easier to make changes to New Prelude if it isn't the default.

 

That's it.

 

 

 

 

Discussing the BBP proposal we also came up with a number of technical questions:

 

Q1

An alternative to Foldable would be

  class Enumerable t where

    toList :: t a -> [a]   -- Implementations should use 'build'

Is Foldable more general (or efficient) than a Enumerable class, plus fusion? 

 

Consider a new data type X a.  I write

     foldX :: (a -> b -> b) -> b -> X a -> b

     foldX = ...lots of code...

 

     toList :: X a -> [a]  {-# INLINE toList #-}

     toList x = build (\c n. foldX c n x)

           

So now toList is small and easy to inline.  Every good list consumer of a call to toList will turn into a call to foldX, which is what we want.

 

Q2

What are the criteria for being in Foldable?

For instance, why are 'sum', 'product' in Foldable, but not 'and', 'or'?

 

 

Q3

What's the relationship of Foldable to GHC.Exts.IsList?

Which also has toList, fromList, and does work with ByteString.

*  For example, could we use IsList instead of Foldable?

    Specifically, Foldable does not use its potential power to apply the type constructor t to different arguments.  (Unlike Traversable which does.)

        foldr :: IsList l => (Item l->b->b) -> b -> l -> b

 

 

  -- Lennart


This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.


This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.

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

Re: Drastic Prelude changes imminent

Johan Tibell-2
Looking at the generalizations in Data.List I find them pretty odd now when I think about it. I'd expect Data.List functions to be monomorphic to lists, just like I expect functions in Data.Map to be monomorphic to maps. Now there might be generalized versions of these functions in e.g. the Prelude, but generalizing Data.List means that I don't even have the monomorphic versions available if I want to resolve ambiguity by using them*.

* It turns out resolving ambiguity is pretty annoying. The type signatures are awkward to write so I end having to write something akin to

    mymap :: (a -> b) -> [a] -> [b]
    mymap = map


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

Re: Drastic Prelude changes imminent

Erik Hesselink
That doesn't really sound feasible, as there would be name clashes
when importing both the Prelude (with generalized functions) and
Data.List (with monomorphic functions). The only way to get
generalized functions and minimize breakage is to also generalize
Data.List.

Erik

On Tue, Jan 27, 2015 at 5:03 PM, Johan Tibell <[hidden email]> wrote:

> Looking at the generalizations in Data.List I find them pretty odd now when
> I think about it. I'd expect Data.List functions to be monomorphic to lists,
> just like I expect functions in Data.Map to be monomorphic to maps. Now
> there might be generalized versions of these functions in e.g. the Prelude,
> but generalizing Data.List means that I don't even have the monomorphic
> versions available if I want to resolve ambiguity by using them*.
>
> * It turns out resolving ambiguity is pretty annoying. The type signatures
> are awkward to write so I end having to write something akin to
>
>     mymap :: (a -> b) -> [a] -> [b]
>     mymap = map
>
>
> _______________________________________________
> 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
|

RE: Drastic Prelude changes imminent

Augustsson, Lennart
But having Data.List export a non-list version of foldr is a terrible idea.

-----Original Message-----
From: Erik Hesselink [mailto:[hidden email]]
Sent: 27 January 2015 16:07
To: Johan Tibell
Cc: Augustsson, Lennart; [hidden email]
Subject: Re: Drastic Prelude changes imminent

That doesn't really sound feasible, as there would be name clashes when importing both the Prelude (with generalized functions) and Data.List (with monomorphic functions). The only way to get generalized functions and minimize breakage is to also generalize Data.List.

Erik

On Tue, Jan 27, 2015 at 5:03 PM, Johan Tibell <[hidden email]> wrote:

> Looking at the generalizations in Data.List I find them pretty odd now
> when I think about it. I'd expect Data.List functions to be
> monomorphic to lists, just like I expect functions in Data.Map to be
> monomorphic to maps. Now there might be generalized versions of these
> functions in e.g. the Prelude, but generalizing Data.List means that I
> don't even have the monomorphic versions available if I want to resolve ambiguity by using them*.
>
> * It turns out resolving ambiguity is pretty annoying. The type
> signatures are awkward to write so I end having to write something
> akin to
>
>     mymap :: (a -> b) -> [a] -> [b]
>     mymap = map
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Drastic Prelude changes imminent

Erik Hesselink
I don't see why from your email, but my only point was that having
both polymorphic versions of functions in the Prelude, and monomorphic
ones in Data.List, will probably be worse than either of the other two
options (the fully polymorphic version being prepared, and the status
quo you want to keep).

Erik

On Tue, Jan 27, 2015 at 5:10 PM, Augustsson, Lennart
<[hidden email]> wrote:

> But having Data.List export a non-list version of foldr is a terrible idea.
>
> -----Original Message-----
> From: Erik Hesselink [mailto:[hidden email]]
> Sent: 27 January 2015 16:07
> To: Johan Tibell
> Cc: Augustsson, Lennart; [hidden email]
> Subject: Re: Drastic Prelude changes imminent
>
> That doesn't really sound feasible, as there would be name clashes when importing both the Prelude (with generalized functions) and Data.List (with monomorphic functions). The only way to get generalized functions and minimize breakage is to also generalize Data.List.
>
> Erik
>
> On Tue, Jan 27, 2015 at 5:03 PM, Johan Tibell <[hidden email]> wrote:
>> Looking at the generalizations in Data.List I find them pretty odd now
>> when I think about it. I'd expect Data.List functions to be
>> monomorphic to lists, just like I expect functions in Data.Map to be
>> monomorphic to maps. Now there might be generalized versions of these
>> functions in e.g. the Prelude, but generalizing Data.List means that I
>> don't even have the monomorphic versions available if I want to resolve ambiguity by using them*.
>>
>> * It turns out resolving ambiguity is pretty annoying. The type
>> signatures are awkward to write so I end having to write something
>> akin to
>>
>>     mymap :: (a -> b) -> [a] -> [b]
>>     mymap = map
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
> This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
> http://www.standardchartered.com/en/incorporation-details.html
>
> Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx.
>
> Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Drastic Prelude changes imminent

Augustsson, Lennart
I'm speaking in general terms, regardless of BBP.  Having Data.List export functions that are not list functions, but overloaded in the list type is so counter-intuitive that my brain hurts.
Where will I find the foldr with type (a->b->b) -> b -> [a] -> b, if not in Data.List?

-----Original Message-----
From: Erik Hesselink [mailto:[hidden email]]
Sent: 27 January 2015 16:15
To: Augustsson, Lennart
Cc: Johan Tibell; [hidden email]
Subject: Re: Drastic Prelude changes imminent

I don't see why from your email, but my only point was that having both polymorphic versions of functions in the Prelude, and monomorphic ones in Data.List, will probably be worse than either of the other two options (the fully polymorphic version being prepared, and the status quo you want to keep).

Erik



This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Drastic Prelude changes imminent

Christopher Done-2
In reply to this post by Erik Hesselink
There's precedence for this, I think: Data.Map, Data.Vector, Data.List
all export monomorphic functions. It's just we don't import Data.List
as L because lists are given special treatment by Haskell 2010. It
makes sense for Prelude to be polymorphic to me.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Drastic Prelude changes imminent

Erik Hesselink
Oh, I agree in general. I just don't see the migration path towards
this, because as you say, Data.List is generally imported unqualified
and often without explicitly naming the imported identifiers.

The only thing I can think of is to generalize Data.List when
generalizing the prelude, but also introduce e.g. Data.List.Mono which
has all the monomorphic variants.

Erik

On Tue, Jan 27, 2015 at 5:21 PM, Christopher Done <[hidden email]> wrote:
> There's precedence for this, I think: Data.Map, Data.Vector, Data.List
> all export monomorphic functions. It's just we don't import Data.List
> as L because lists are given special treatment by Haskell 2010. It
> makes sense for Prelude to be polymorphic to me.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Drastic Prelude changes imminent

Yitzchak Gale
In reply to this post by Erik Hesselink
First of all, I am very strongly in favor of Lennart's proposal
of slowing down the BBP.

This discussion is now moving in the direction of changes or
alternatives to BBP itself. That is a worthwhile discussion,
but it's not practical until we first come to a conclusion about
Lennart's original proposal. For now, what is on the table is
to find a way to swap BBP, exactly as it is now, in or out
using some simple mechanism like a pragma.

The proposed syntax LANGUAGE Prelude=AlternativePrelude
is nice, but the difficulty in finding a Proposal 3 shows that
this syntax is not good enough. We need a combined
Proposal 1 and Proposal 3 that works something like this:

The base package comes with two versions of each of
the affected modules. Something like this:

Prelude.Traditional
Prelude.Alternative

Data.List.Traditional
Data.List.Alternative

etc.

Then we need some simple mechanism - a LANGUAGE
pragma, or whatever - that swaps all at once which of
the two sets are re-exported by the standard modules.

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

Re: Drastic Prelude changes imminent

David Feuer
I'm trying to understand why people with (serious, legitimate)
concerns about BBP didn't come out of the woodwork until RC2. I fear
it's likely that nothing can be done to change this until 7.12 in any
case.

For the record, I'm not a huge fan of the Foldable abstraction myself;
I just don't think now is a good time for that discussion.

On Tue, Jan 27, 2015 at 11:35 AM, Yitzchak Gale <[hidden email]> wrote:

> First of all, I am very strongly in favor of Lennart's proposal
> of slowing down the BBP.
>
> This discussion is now moving in the direction of changes or
> alternatives to BBP itself. That is a worthwhile discussion,
> but it's not practical until we first come to a conclusion about
> Lennart's original proposal. For now, what is on the table is
> to find a way to swap BBP, exactly as it is now, in or out
> using some simple mechanism like a pragma.
>
> The proposed syntax LANGUAGE Prelude=AlternativePrelude
> is nice, but the difficulty in finding a Proposal 3 shows that
> this syntax is not good enough. We need a combined
> Proposal 1 and Proposal 3 that works something like this:
>
> The base package comes with two versions of each of
> the affected modules. Something like this:
>
> Prelude.Traditional
> Prelude.Alternative
>
> Data.List.Traditional
> Data.List.Alternative
>
> etc.
>
> Then we need some simple mechanism - a LANGUAGE
> pragma, or whatever - that swaps all at once which of
> the two sets are re-exported by the standard modules.
>
> -Yitz
> _______________________________________________
> 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
|

RE: Drastic Prelude changes imminent

Augustsson, Lennart
Perhaps because a lot of people didn't know about it?
Simon PJ didn't know until we told him on Friday, so I don't think the change has been that well advertised.

-----Original Message-----
From: Libraries [mailto:[hidden email]] On Behalf Of David Feuer
Sent: 27 January 2015 17:07
To: Yitzchak Gale
Cc: [hidden email]
Subject: Re: Drastic Prelude changes imminent

I'm trying to understand why people with (serious, legitimate) concerns about BBP didn't come out of the woodwork until RC2. I fear it's likely that nothing can be done to change this until 7.12 in any case.

For the record, I'm not a huge fan of the Foldable abstraction myself; I just don't think now is a good time for that discussion.


This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Drastic Prelude changes imminent

Gershom Bazerman
I think that _if_ there had been a better organized, more clarifying discussion on the scope of BBP earlier (one was promised after Neil raised concerns, but I think it fell by the wayside), then we might not be in this boat.

Now, whatever the “right” thing is eventually, it does feel like we need to apply brakes until people can settle in further. I know people will be disappointed no matter what happens, and they will feel this stuff has moved slowly enough for long enough.

However, without having had that discussion, I don’t see how we can move forward.

The proposal Lennart and Simon have therefore seems good and necessary, save for the issue of how BBP infects Data.List in particular as well. 

I think we should go with it, and _also_ just have Data.List always export the monomorphic functions for now. I recognize that this means even with AlternativePrelude on, people will not get the full niceness of the “BBP experience”. However, it seems as close as we can get, to my mind, without creating greater headaches and issues all around.

We could perhaps also insert a warning encouraging people to import Data.List qualified, either in this GHC of the next release. This would allow BBP to proceed in a relatively breakage-free way in the future without needing to generalize the Data.List module.

Cheers,
Gershom


On January 27, 2015 at 12:14:03 PM, Augustsson, Lennart ([hidden email]) wrote:

> Perhaps because a lot of people didn't know about it?
> Simon PJ didn't know until we told him on Friday, so I don't think the change has been that  
> well advertised.
>  
> -----Original Message-----
> From: Libraries [mailto:[hidden email]] On Behalf Of David Feuer  
> Sent: 27 January 2015 17:07
> To: Yitzchak Gale
> Cc: [hidden email]
> Subject: Re: Drastic Prelude changes imminent
>  
> I'm trying to understand why people with (serious, legitimate) concerns about BBP didn't  
> come out of the woodwork until RC2. I fear it's likely that nothing can be done to change  
> this until 7.12 in any case.
>  
> For the record, I'm not a huge fan of the Foldable abstraction myself; I just don't think  
> now is a good time for that discussion.
>  
>  
> This email and any attachments are confidential and may also be privileged. If you are  
> not the intended recipient, please delete all copies and notify the sender immediately.  
> You may wish to refer to the incorporation details of Standard Chartered PLC, Standard  
> Chartered Bank and their subsidiaries at
> http://www.standardchartered.com/en/incorporation-details.html
>  
> Insofar as this communication contains any market commentary, the market commentary  
> has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate.  
> It is not and does not constitute research material, independent research, recommendation  
> or financial advice. Any market commentary is for information purpose only and shall  
> not be relied for any other purpose, and is subject to the relevant disclaimers available  
> at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx.  
>  
> Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx 
> for important information with respect to derivative products.
> _______________________________________________
> 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
|

Re: Drastic Prelude changes imminent

Brandon Allbery
On Tue, Jan 27, 2015 at 12:25 PM, Gershom B <[hidden email]> wrote:
I think that _if_ there had been a better organized, more clarifying discussion on the scope of BBP earlier (one was promised after Neil raised concerns, but I think it fell by the wayside), then we might not be in this boat.

Agreed. I knew this was coming from various mentions, but there was not a good overview of what was going on and what effects it would have until this thread. This makes me think that it might be wise to back off until 7.12.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

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

Re: Drastic Prelude changes imminent

Simon Marlow-7
In reply to this post by Augustsson, Lennart
On 27/01/2015 10:32, Augustsson, Lennart wrote:
> Proposal 1:
>
> *    Add a new pragma
>
>          {-# LANGUAGE Prelude=AlternativePrelude #-}

As I mentioned to Simon PJ, I don't think this is the best way to solve
the problem, because adding a new extension brings new
backwards-compatibility issues on top of the ones we're trying to solve.
  Users will need to employ flags in their .cabal file, or #ifdefs in
their source code, to account for the fact that only GHC 7.10 supports
the new option.

Furthermore, every GHC version already has the necessary functionality
to do this, so we don't need to add a new flag.  You can either (a) use
{-# LANGUAGE NoImplicitPrelude #-} together with import MyPrelude, or
(b) use import Prelude (); import MyPrelude.  Slightly more characters,
but entirely backwards-compatible - I think that's a worthy tradeoff.

FWIW, I agreed with Neil when he brought up the issue of the new Prelude
changes a while ago.

Cheers,
Simon






>        *   This is a new feature, but it is easy and low-risk to implement.
>
>        *   Which Prelude you use really is a language choice;
> appropriate for a LANGUAGE pragma.
>
>        *   Semantics is name-space only: import Prelude (); import
> AlternativePrelude
>
>        *   No effect on desugaring or typing of built-in syntax (list
> comprehensions, do-notation etc).
>
> *    Ship with both old and new prelude.
>
> *    So now old and new behaviour are easy to achieve, in the module or
> in a .cabal file.
>
> *    The question becomes "what is the default".
>
> Proposal 2:
>
> *    Make the default be the old rather than the new.
>
>        *   Altering the default Prelude API should be done slowly, with
> lots of warning; because all users get it willy-nilly.
>
>        *   Unlike AMP, the change is controversial (clearly).
>
>        *   Easier to make changes to New Prelude if it isn't the default.
>
> That's it.
>
> Discussing the BBP proposal we also came up with a number of technical
> questions:
>
> Q1
>
> An alternative to Foldable would be
>
>    class Enumerable t where
>
>      toList :: t a -> [a]   -- Implementations should use 'build'
>
> Is Foldable more general (or efficient) than a Enumerable class, plus
> fusion?
>
> Consider a new data type X a.  I write
>
>       foldX :: (a -> b -> b) -> b -> X a -> b
>
>       foldX = ...lots of code...
>
>       toList :: X a -> [a]  {-# INLINE toList #-}
>
>       toList x = build (\c n. foldX c n x)
>
> So now toList is small and easy to inline.  Every good list consumer of
> a call to toList will turn into a call to foldX, which is what we want.
>
> Q2
>
> What are the criteria for being in Foldable?
>
> For instance, why are 'sum', 'product' in Foldable, but not 'and', 'or'?
>
> Q3
>
> What's the relationship of Foldable to GHC.Exts.IsList?
>
> Which also has toList, fromList, and does work with ByteString.
>
> *  For example, could we use IsList instead of Foldable?
>
>      Specifically, Foldable does not use its potential power to apply
> the type constructor t to different arguments.  (Unlike Traversable
> which does.)
>
>          foldr :: IsList l => (Item l->b->b) -> b -> l -> b
>
>    -- Lennart
>
>
> This email and any attachments are confidential and may also be
> privileged. If you are not the intended recipient, please delete all
> copies and notify the sender immediately. You may wish to refer to the
> incorporation details of Standard Chartered PLC, Standard Chartered Bank
> and their subsidiaries at
> http://www.standardchartered.com/en/incorporation-details.html
>
> Insofar as this communication contains any market commentary, the market
> commentary has been prepared by a sales and/or trading desk of Standard
> Chartered Bank or its affiliate. It is not and does not constitute
> research material, independent research, recommendation or financial
> advice. Any market commentary is for information purpose only and shall
> not be relied for any other purpose, and is subject to the relevant
> disclaimers available at
> http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx.
>
> Please visit
> http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx
> for important information with respect to derivative products.
>
>
> _______________________________________________
> 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
|

Re: Drastic Prelude changes imminent

Simon Marlow-7
In reply to this post by Augustsson, Lennart
On 27/01/2015 11:26, Augustsson, Lennart wrote:
> That's very different since it changes how desugaring works.
> With NoImplicitPrelude desugaring uses unqualified names.  It's a rather fragile pragma.

You're thinking of RebindableSyntax.  NoImplicitPrelude has no effect on
desugaring.

Cheers,
Simon




> -----Original Message-----
> From: Erik Hesselink [mailto:[hidden email]]
> Sent: 27 January 2015 11:11
> To: Augustsson, Lennart
> Cc: [hidden email]
> Subject: Re: Drastic Prelude changes imminent
>
> On Tue, Jan 27, 2015 at 11:32 AM, Augustsson, Lennart <[hidden email]> wrote:
>> *    Add a new pragma
>>          {-# LANGUAGE Prelude=AlternativePrelude #-}
>>        *   Semantics is name-space only: import Prelude (); import
>> AlternativePrelude
>
> I don't have any opinion on the full proposal yet, but I usually use "{-# LANGUAGE NoImplicitPrelude #-}" when using an alternate prelude.
> Is there any different between that and "import Prelude ()"?
>
> Erik
>
> This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
> http://www.standardchartered.com/en/incorporation-details.html
>
> Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx.
>
> Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.
> _______________________________________________
> 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
|

Re: Drastic Prelude changes imminent

Simon Marlow-7
In reply to this post by Augustsson, Lennart
On 27/01/2015 17:13, Augustsson, Lennart wrote:
> Perhaps because a lot of people didn't know about it?
> Simon PJ didn't know until we told him on Friday, so I don't think the change has been that well advertised.

There was the reddit discussion of Neil's blogpost [1], where most of
the people responding seemed to be in favour of the change.  I assumed
the ship had sailed and decided to live with it.

http://www.reddit.com/r/haskell/comments/2hzqii/neil_mitchells_haskell_blog_why/

Cheers,
Simon



>
> -----Original Message-----
> From: Libraries [mailto:[hidden email]] On Behalf Of David Feuer
> Sent: 27 January 2015 17:07
> To: Yitzchak Gale
> Cc: [hidden email]
> Subject: Re: Drastic Prelude changes imminent
>
> I'm trying to understand why people with (serious, legitimate) concerns about BBP didn't come out of the woodwork until RC2. I fear it's likely that nothing can be done to change this until 7.12 in any case.
>
> For the record, I'm not a huge fan of the Foldable abstraction myself; I just don't think now is a good time for that discussion.
>
>
> This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
> http://www.standardchartered.com/en/incorporation-details.html
>
> Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx.
>
> Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
1234 ... 7