The future of the haskell2010/haskell98 packages - AKA Trac #9590

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

The future of the haskell2010/haskell98 packages - AKA Trac #9590

Austin Seipp-5
Hello developers, users, friends,

I'd like you all to weigh in on something - a GHC bug report, that has
happened as a result of making Applicative a superclass of Monad:

https://ghc.haskell.org/trac/ghc/ticket/9590

The very condensed version is this: because haskell2010/haskell98
packages try to be fairly strictly conforming, they do not have
modules like Control.Applicative.

Unfortunately, due to the way these packages are structured, many
things are simply re-exported from base, like `Monad`. But
`Applicative` is not, and cannot be imported if you use -XHaskell2010
and the haskell2010 package.

The net result here is that haskell98/haskell2010 are hopelessly
broken in the current state: it's impossible to define an instance of
`Monad`, because you cannot define an instance of `Applicative`,
because you can't import it in the first place!

This leaves us in quite a pickle.

So I ask: Friends, what do you think we should do? I am particularly
interested in users/developers of current Haskell2010 packages - not
just code that may *be* standard Haskell - code that implies a
dependency on it.

There was a short discussion between me and Simon Marlow about this in
the morning, and again on IRC this morning between me, Duncan, Edward
K, and Herbert.

Basically, I only see one of two options:

 - We could make GHC support both: a version of `Monad` without
`Applicative`, and one with it. This creates some complication in the
desugarer, where GHC takes care of `do` syntax (and thus needs to be
aware of `Monad`'s definition and location). But it is, perhaps, quite
doable.

 - We change both packages to export `Applicative` and follow the API
changes in `base` accordingly.

Note that #1 above is contingent on three things:

 1) There is interest in this actually happening, and these separate
APIs being supported. If there is not significant interest in
maintaining this, it's unclear if we should go for it.

 2) It's not overly monstrously complex (I don't think it necessarily
will be, but it might be.)

 3) You can't like `haskell2010` packages and `base` packages together
in the general case, but, AFAIK, this wasn't the case before either.

I'd really appreciate your thoughts. This must be sorted out for 7.10
somehow; the current situation is hopelessly busted.

--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: The future of the haskell2010/haskell98 packages - AKA Trac #9590

Simon Peyton Jones
I hate #1.  Let's avoid if unless it's really crucial to some of our users.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:[hidden email]] On Behalf Of Austin
| Seipp
| Sent: 30 September 2014 21:21
| To: [hidden email]; [hidden email]
| Subject: The future of the haskell2010/haskell98 packages - AKA Trac
| #9590
|
| Hello developers, users, friends,
|
| I'd like you all to weigh in on something - a GHC bug report, that has
| happened as a result of making Applicative a superclass of Monad:
|
| https://ghc.haskell.org/trac/ghc/ticket/9590
|
| The very condensed version is this: because haskell2010/haskell98
| packages try to be fairly strictly conforming, they do not have
| modules like Control.Applicative.
|
| Unfortunately, due to the way these packages are structured, many
| things are simply re-exported from base, like `Monad`. But
| `Applicative` is not, and cannot be imported if you use -XHaskell2010
| and the haskell2010 package.
|
| The net result here is that haskell98/haskell2010 are hopelessly
| broken in the current state: it's impossible to define an instance of
| `Monad`, because you cannot define an instance of `Applicative`,
| because you can't import it in the first place!
|
| This leaves us in quite a pickle.
|
| So I ask: Friends, what do you think we should do? I am particularly
| interested in users/developers of current Haskell2010 packages - not
| just code that may *be* standard Haskell - code that implies a
| dependency on it.
|
| There was a short discussion between me and Simon Marlow about this in
| the morning, and again on IRC this morning between me, Duncan, Edward
| K, and Herbert.
|
| Basically, I only see one of two options:
|
|  - We could make GHC support both: a version of `Monad` without
| `Applicative`, and one with it. This creates some complication in the
| desugarer, where GHC takes care of `do` syntax (and thus needs to be
| aware of `Monad`'s definition and location). But it is, perhaps, quite
| doable.
|
|  - We change both packages to export `Applicative` and follow the API
| changes in `base` accordingly.
|
| Note that #1 above is contingent on three things:
|
|  1) There is interest in this actually happening, and these separate
| APIs being supported. If there is not significant interest in
| maintaining this, it's unclear if we should go for it.
|
|  2) It's not overly monstrously complex (I don't think it necessarily
| will be, but it might be.)
|
|  3) You can't like `haskell2010` packages and `base` packages together
| in the general case, but, AFAIK, this wasn't the case before either.
|
| I'd really appreciate your thoughts. This must be sorted out for 7.10
| somehow; the current situation is hopelessly busted.
|
| --
| Regards,
|
| Austin Seipp, Haskell Consultant
| Well-Typed LLP, http://www.well-typed.com/
| _______________________________________________
| ghc-devs mailing list
| [hidden email]
| http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590

Malcolm Wallace-2
In reply to this post by Austin Seipp-5
How about doing the honest thing, and withdrawing both packages in ghc-7.10?  Haskell'98 is now 15 years old, and the 2010 standard was never really popular anyway.

 Regards,
    Malcolm

On 30 Sep 2014, at 21:21, Austin Seipp <[hidden email]> wrote:

Hello developers, users, friends,

I'd like you all to weigh in on something - a GHC bug report, that has
happened as a result of making Applicative a superclass of Monad:

https://ghc.haskell.org/trac/ghc/ticket/9590

The very condensed version is this: because haskell2010/haskell98
packages try to be fairly strictly conforming, they do not have
modules like Control.Applicative.

Unfortunately, due to the way these packages are structured, many
things are simply re-exported from base, like `Monad`. But
`Applicative` is not, and cannot be imported if you use -XHaskell2010
and the haskell2010 package.

The net result here is that haskell98/haskell2010 are hopelessly
broken in the current state: it's impossible to define an instance of
`Monad`, because you cannot define an instance of `Applicative`,
because you can't import it in the first place!

This leaves us in quite a pickle.

So I ask: Friends, what do you think we should do? I am particularly
interested in users/developers of current Haskell2010 packages - not
just code that may *be* standard Haskell - code that implies a
dependency on it.

There was a short discussion between me and Simon Marlow about this in
the morning, and again on IRC this morning between me, Duncan, Edward
K, and Herbert.

Basically, I only see one of two options:

- We could make GHC support both: a version of `Monad` without
`Applicative`, and one with it. This creates some complication in the
desugarer, where GHC takes care of `do` syntax (and thus needs to be
aware of `Monad`'s definition and location). But it is, perhaps, quite
doable.

- We change both packages to export `Applicative` and follow the API
changes in `base` accordingly.

Note that #1 above is contingent on three things:

1) There is interest in this actually happening, and these separate
APIs being supported. If there is not significant interest in
maintaining this, it's unclear if we should go for it.

2) It's not overly monstrously complex (I don't think it necessarily
will be, but it might be.)

3) You can't like `haskell2010` packages and `base` packages together
in the general case, but, AFAIK, this wasn't the case before either.

I'd really appreciate your thoughts. This must be sorted out for 7.10
somehow; the current situation is hopelessly busted.

--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590

Brandon Allbery
On Tue, Sep 30, 2014 at 5:00 PM, Malcolm Wallace <[hidden email]> wrote:
How about doing the honest thing, and withdrawing both packages in ghc-7.10?  Haskell'98 is now 15 years old, and the 2010 standard was never really popular anyway.

There are apparently educators using both, although they're not used much if at all in production.

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

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

Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590

Ryan Trinkle-3
Would something like John Meacham's class alias proposal (http://repetae.net/recent/out/classalias.html) help alleviate this problem?

On Tue, Sep 30, 2014 at 5:02 PM, Brandon Allbery <[hidden email]> wrote:
On Tue, Sep 30, 2014 at 5:00 PM, Malcolm Wallace <[hidden email]> wrote:
How about doing the honest thing, and withdrawing both packages in ghc-7.10?  Haskell'98 is now 15 years old, and the 2010 standard was never really popular anyway.

There are apparently educators using both, although they're not used much if at all in production.

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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



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

Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590

Austin Seipp-5
Hi Ryan,

Yes, that or one of the various superclass instance proposals would
probably solve this without too much grief, since we could simply
export Applicative, then automatically get an instance for it
afterwords at no cost.

This was very very briefly discussed yesterday, but I left it out of
the 'Possibilities' list here because it is simply contingent on too
much work, and too much discussion, in too short a span of time. There
have probably been a dozen proposals for this kind of functionality,
and I don't think any of them ever even got to the implementation
stage.

Unless someone has a hidden, ready-to-go patch with these features and
it'll be committed very very soon (which I unfortunately doubt), I
just don't think it's realistic to consider these approaches as
solutions right now.

On Tue, Sep 30, 2014 at 6:04 PM, Ryan Trinkle <[hidden email]> wrote:

> Would something like John Meacham's class alias proposal
> (http://repetae.net/recent/out/classalias.html) help alleviate this problem?
>
> On Tue, Sep 30, 2014 at 5:02 PM, Brandon Allbery <[hidden email]>
> wrote:
>>
>> On Tue, Sep 30, 2014 at 5:00 PM, Malcolm Wallace <[hidden email]>
>> wrote:
>>>
>>> How about doing the honest thing, and withdrawing both packages in
>>> ghc-7.10?  Haskell'98 is now 15 years old, and the 2010 standard was never
>>> really popular anyway.
>>
>>
>> There are apparently educators using both, although they're not used much
>> if at all in production.
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> [hidden email]
>> [hidden email]
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590

Austin Seipp-5
In reply to this post by Malcolm Wallace-2
Hi Malcolm,

Withdrawing the packages from GHC's distribution is certainly a
possibility. We did briefly raise that point when we talked yesterday
too, but it wasn't discussed much.

Perhaps some others feel the same, but I imagine more people would be
OK with #2 above as opposed to eliminating it, since we already
lightly break some things anyway. Hopefully we'll really find out
soon.

On Tue, Sep 30, 2014 at 4:00 PM, Malcolm Wallace <[hidden email]> wrote:

> How about doing the honest thing, and withdrawing both packages in ghc-7.10?  Haskell'98 is now 15 years old, and the 2010 standard was never really popular anyway.
>
>  Regards,
>     Malcolm
>
> On 30 Sep 2014, at 21:21, Austin Seipp <[hidden email]> wrote:
>
> Hello developers, users, friends,
>
> I'd like you all to weigh in on something - a GHC bug report, that has
> happened as a result of making Applicative a superclass of Monad:
>
> https://ghc.haskell.org/trac/ghc/ticket/9590
>
> The very condensed version is this: because haskell2010/haskell98
> packages try to be fairly strictly conforming, they do not have
> modules like Control.Applicative.
>
> Unfortunately, due to the way these packages are structured, many
> things are simply re-exported from base, like `Monad`. But
> `Applicative` is not, and cannot be imported if you use -XHaskell2010
> and the haskell2010 package.
>
> The net result here is that haskell98/haskell2010 are hopelessly
> broken in the current state: it's impossible to define an instance of
> `Monad`, because you cannot define an instance of `Applicative`,
> because you can't import it in the first place!
>
> This leaves us in quite a pickle.
>
> So I ask: Friends, what do you think we should do? I am particularly
> interested in users/developers of current Haskell2010 packages - not
> just code that may *be* standard Haskell - code that implies a
> dependency on it.
>
> There was a short discussion between me and Simon Marlow about this in
> the morning, and again on IRC this morning between me, Duncan, Edward
> K, and Herbert.
>
> Basically, I only see one of two options:
>
> - We could make GHC support both: a version of `Monad` without
> `Applicative`, and one with it. This creates some complication in the
> desugarer, where GHC takes care of `do` syntax (and thus needs to be
> aware of `Monad`'s definition and location). But it is, perhaps, quite
> doable.
>
> - We change both packages to export `Applicative` and follow the API
> changes in `base` accordingly.
>
> Note that #1 above is contingent on three things:
>
> 1) There is interest in this actually happening, and these separate
> APIs being supported. If there is not significant interest in
> maintaining this, it's unclear if we should go for it.
>
> 2) It's not overly monstrously complex (I don't think it necessarily
> will be, but it might be.)
>
> 3) You can't like `haskell2010` packages and `base` packages together
> in the general case, but, AFAIK, this wasn't the case before either.
>
> I'd really appreciate your thoughts. This must be sorted out for 7.10
> somehow; the current situation is hopelessly busted.
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590

Bulat Ziganshin-2
In reply to this post by Brandon Allbery
Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590 Hello Brandon,

Wednesday, October 1, 2014, 1:02:54 AM, you wrote:


On Tue, Sep 30, 2014 at 5:00 PM, Malcolm Wallace <[hidden email]> wrote:
How about doing the honest thing, and withdrawing both packages in ghc-7.10?  Haskell'98 is now 15 years old, and the 2010 standard was never really popular anyway.

There are apparently educators using both, although they're not used much if at all in production.


does they need latest GHC version? an option may be to drop support of Haskell'98 in GHC 7.10, then implement superclass proposal in GHC 7.12 and return haskell'98 support




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




-- 
Best regards,
 Bulat                            
[hidden email]
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users