Re: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept
(replying to the whole list, full quote) Am Donnerstag, dem 08.12.2022 um 11:23 +0300 schrieb Vladislav Zavialov:
I agree with your observation that namespaced imports are somewhat different from simply specifying the namespace of a single name, so they could be separated into their own extension. But if that is the reasoning that we choose to follow, then the changes in #281 should *definitely* go into their own extension: they affect not just names but entire expressions and patterns, including their grammar (not just namespacing).
The only reason the changes in #270 and #281 are included in ExplicitNamespaces is to reduce the amount of language flags. If you prefer fine-grained control and immutable extensions, then both of those changes need separate flags for them.
So, if we are consistent, we have two options: 1. Include changes in #270 and #281 in ExplicitNamespaces on the grounds that they include explicitly specify a namespace (even though that is not the only thing they do) 2. Create separate language extension flags: NamespacedImports and TypesInExpressions (names to be discussed)
I happen to prefer (1), and that is the approach that the proposals currently follow, but I am not opposed to (2) either.
I don’t prefer fine-grained flags per se. In fact, my ideal world is one perfect language with no flags :-). So I think I’d prefer all under ExplicitNamespaces as well, and I think the only reason I am hesitant is that I believe the old ExplicitNamespaces should have been in GHC2021, so it should be in GHC2023, and am unsure if the (comprehensive) ExplicitNamespaces should be there. This gives us (at least) these options: 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, introduce one or two new extensions for the newer changes. 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, disregarding issue #551. 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, arguing that GHC20xx allows more liberal (backward-compatibile) changes than, say, Haskell2010 would allow. Certainly 1 is the least bold move. I am not sure what the best way forwards is, and welcome other opinions. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
As it currently stands, it seems to me that the proposal is pretty modest. I'm in favour of the proposal, provided that the technical details are resolved to Joachim satisfaction. On Thu, 8 Dec 2022 at 09:33, Joachim Breitner <mail@joachim-breitner.de> wrote:
(replying to the whole list, full quote)
Am Donnerstag, dem 08.12.2022 um 11:23 +0300 schrieb Vladislav Zavialov:
I agree with your observation that namespaced imports are somewhat different from simply specifying the namespace of a single name, so they could be separated into their own extension. But if that is the reasoning that we choose to follow, then the changes in #281 should *definitely* go into their own extension: they affect not just names but entire expressions and patterns, including their grammar (not just namespacing).
The only reason the changes in #270 and #281 are included in ExplicitNamespaces is to reduce the amount of language flags. If you prefer fine-grained control and immutable extensions, then both of those changes need separate flags for them.
So, if we are consistent, we have two options: 1. Include changes in #270 and #281 in ExplicitNamespaces on the grounds that they include explicitly specify a namespace (even though that is not the only thing they do) 2. Create separate language extension flags: NamespacedImports and TypesInExpressions (names to be discussed)
I happen to prefer (1), and that is the approach that the proposals currently follow, but I am not opposed to (2) either.
I don’t prefer fine-grained flags per se. In fact, my ideal world is one perfect language with no flags :-). So I think I’d prefer all under ExplicitNamespaces as well, and I think the only reason I am hesitant is that I believe the old ExplicitNamespaces should have been in GHC2021, so it should be in GHC2023, and am unsure if the (comprehensive) ExplicitNamespaces should be there.
This gives us (at least) these options:
1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, introduce one or two new extensions for the newer changes. 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, disregarding issue #551. 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, arguing that GHC20xx allows more liberal (backward-compatibile) changes than, say, Haskell2010 would allow.
Certainly 1 is the least bold move. I am not sure what the best way forwards is, and welcome other opinions.
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
I'm broadly in favour of accepting the proposal. I realise the history is complex here, so I don't think we should ask anyone to rewrite things further, though in general it would be nicer to have separate proposals for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the changes to imports (which as Joachim points out raise issues). I'm a bit concerned that the proposal does not motivate or specify -Wpattern-namespace-qualified very well. On 08/12/2022 08:33, Joachim Breitner wrote:
...
This gives us (at least) these options:
1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, introduce one or two new extensions for the newer changes. 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, disregarding issue #551. 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, arguing that GHC20xx allows more liberal (backward-compatibile) changes than, say, Haskell2010 would allow.
Certainly 1 is the least bold move. I am not sure what the best way forwards is, and welcome other opinions.
I would prefer a variant of 1: allow "data" as a keyword in import lists under ExplicitNamespaces, but make the other changes under other extensions. As I've said previously, I have a general preference for multiple small, orthogonal extensions rather than changing existing extensions to add unrelated features that happen to be in similar territory. I realise this is controversial, of course. Cheers, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 I realised I'm unclear how the proposed extensions to ExplicitNamespaces are supposed to work. The existing situation is apparently that for a (non-punned) data constructor, it is possible to use either a pattern or type qualifier in an import list (presumably because DataKinds means the constructor is in scope at both the term and type levels), and the imported constructor is then usable in both contexts. For example, the following is accepted at present: module M where data T = MkT {-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level The present proposal says "With type specified in the import, only identifiers belonging to the type namespace will be brought into the scope." I'm not exactly sure how to interpret this, does it mean the following alternative will be accepted or rejected? module N where import M type (MkT) v = MkT I'm worried we will end up with a situation where ExplicitNamespaces does subtly different things depending on the position of the keyword. In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Given the discussion about exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus separate extensions, perhaps we should accept the parts relating to -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be proposed separately? Cheers, Adam On 09/12/2022 11:11, Adam Gundry wrote:
I'm broadly in favour of accepting the proposal. I realise the history is complex here, so I don't think we should ask anyone to rewrite things further, though in general it would be nicer to have separate proposals for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the changes to imports (which as Joachim points out raise issues).
I'm a bit concerned that the proposal does not motivate or specify -Wpattern-namespace-qualified very well.
On 08/12/2022 08:33, Joachim Breitner wrote:
...
This gives us (at least) these options:
1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, introduce one or two new extensions for the newer changes. 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, disregarding issue #551. 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, arguing that GHC20xx allows more liberal (backward-compatibile) changes than, say, Haskell2010 would allow.
Certainly 1 is the least bold move. I am not sure what the best way forwards is, and welcome other opinions.
I would prefer a variant of 1: allow "data" as a keyword in import lists under ExplicitNamespaces, but make the other changes under other extensions.
As I've said previously, I have a general preference for multiple small, orthogonal extensions rather than changing existing extensions to add unrelated features that happen to be in similar territory. I realise this is controversial, of course.
Cheers,
Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
{-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level
Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above. In general, I don't feel the extensions to ExplicitNamespaces included
in the proposal are very clearly specified.
Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>. It only covers import M *type * import M *data *as MD where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal? Simon On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam@well-typed.com> wrote:
Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 I realised I'm unclear how the proposed extensions to ExplicitNamespaces are supposed to work. The existing situation is apparently that for a (non-punned) data constructor, it is possible to use either a pattern or type qualifier in an import list (presumably because DataKinds means the constructor is in scope at both the term and type levels), and the imported constructor is then usable in both contexts.
For example, the following is accepted at present:
module M where data T = MkT
{-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level
The present proposal says "With type specified in the import, only identifiers belonging to the type namespace will be brought into the scope." I'm not exactly sure how to interpret this, does it mean the following alternative will be accepted or rejected?
module N where import M type (MkT) v = MkT
I'm worried we will end up with a situation where ExplicitNamespaces does subtly different things depending on the position of the keyword.
In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Given the discussion about exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus separate extensions, perhaps we should accept the parts relating to -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be proposed separately?
Cheers,
Adam
On 09/12/2022 11:11, Adam Gundry wrote:
I'm broadly in favour of accepting the proposal. I realise the history is complex here, so I don't think we should ask anyone to rewrite things further, though in general it would be nicer to have separate proposals for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the changes to imports (which as Joachim points out raise issues).
I'm a bit concerned that the proposal does not motivate or specify -Wpattern-namespace-qualified very well.
On 08/12/2022 08:33, Joachim Breitner wrote:
...
This gives us (at least) these options:
1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, introduce one or two new extensions for the newer changes. 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, disregarding issue #551. 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, arguing that GHC20xx allows more liberal (backward-compatibile) changes than, say, Haskell2010 would allow.
Certainly 1 is the least bold move. I am not sure what the best way forwards is, and welcome other opinions.
I would prefer a variant of 1: allow "data" as a keyword in import lists under ExplicitNamespaces, but make the other changes under other extensions.
As I've said previously, I have a general preference for multiple small, orthogonal extensions rather than changing existing extensions to add unrelated features that happen to be in similar territory. I realise this is controversial, of course.
Cheers,
Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
On 12/12/2022 11:39, Simon Peyton Jones wrote:
{-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level
Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above.
The nested use is already possible with ExplicitNamespaces. Currently it allows import M (T(type MkT)) import M (type MkT) import M (pattern MkT) whereas the proposal extends it to add the possibility to write import M type (MkT) import M data (MkT) import M (data MkT)
In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified.
Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>. It only covers import M *type * import M *data *as MD where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal?
I'm trying to understand what import M type (MkT) means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing import M (T(type MkT)) which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581). I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something? Cheers, Adam
On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote:
Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> I realised I'm unclear how the proposed extensions to ExplicitNamespaces are supposed to work. The existing situation is apparently that for a (non-punned) data constructor, it is possible to use either a pattern or type qualifier in an import list (presumably because DataKinds means the constructor is in scope at both the term and type levels), and the imported constructor is then usable in both contexts.
For example, the following is accepted at present:
module M where data T = MkT
{-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level
The present proposal says "With type specified in the import, only identifiers belonging to the type namespace will be brought into the scope." I'm not exactly sure how to interpret this, does it mean the following alternative will be accepted or rejected?
module N where import M type (MkT) v = MkT
I'm worried we will end up with a situation where ExplicitNamespaces does subtly different things depending on the position of the keyword.
In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Given the discussion about exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus separate extensions, perhaps we should accept the parts relating to -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be proposed separately?
Cheers,
Adam
On 09/12/2022 11:11, Adam Gundry wrote: > I'm broadly in favour of accepting the proposal. I realise the history > is complex here, so I don't think we should ask anyone to rewrite things > further, though in general it would be nicer to have separate proposals > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the > changes to imports (which as Joachim points out raise issues). > > I'm a bit concerned that the proposal does not motivate or specify > -Wpattern-namespace-qualified very well. > > > On 08/12/2022 08:33, Joachim Breitner wrote: >> ... >> >> This gives us (at least) these options: >> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, >> introduce one or two new extensions for the newer changes. >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >> disregarding issue #551. >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >> arguing that GHC20xx allows more liberal (backward-compatibile) >> changes than, say, Haskell2010 would allow. >> >> Certainly 1 is the least bold move. I am not sure what the best way >> forwards is, and welcome other opinions. > > I would prefer a variant of 1: allow "data" as a keyword in import lists > under ExplicitNamespaces, but make the other changes under other > extensions. > > As I've said previously, I have a general preference for multiple small, > orthogonal extensions rather than changing existing extensions to add > unrelated features that happen to be in similar territory. I realise > this is controversial, of course. > > Cheers, > > Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly. Chris
On 12 Dec 2022, at 12:21, Adam Gundry <adam@well-typed.com> wrote:
On 12/12/2022 11:39, Simon Peyton Jones wrote:
{-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above.
The nested use is already possible with ExplicitNamespaces. Currently it allows
import M (T(type MkT)) import M (type MkT) import M (pattern MkT)
whereas the proposal extends it to add the possibility to write
import M type (MkT) import M data (MkT) import M (data MkT)
In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>. It only covers import M *type * import M *data *as MD where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal?
I'm trying to understand what
import M type (MkT)
means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing
import M (T(type MkT))
which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581).
I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something?
Cheers,
Adam
On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote: Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> I realised I'm unclear how the proposed extensions to ExplicitNamespaces are supposed to work. The existing situation is apparently that for a (non-punned) data constructor, it is possible to use either a pattern or type qualifier in an import list (presumably because DataKinds means the constructor is in scope at both the term and type levels), and the imported constructor is then usable in both contexts. For example, the following is accepted at present: module M where data T = MkT {-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level The present proposal says "With type specified in the import, only identifiers belonging to the type namespace will be brought into the scope." I'm not exactly sure how to interpret this, does it mean the following alternative will be accepted or rejected? module N where import M type (MkT) v = MkT I'm worried we will end up with a situation where ExplicitNamespaces does subtly different things depending on the position of the keyword. In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Given the discussion about exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus separate extensions, perhaps we should accept the parts relating to -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be proposed separately? Cheers, Adam On 09/12/2022 11:11, Adam Gundry wrote: > I'm broadly in favour of accepting the proposal. I realise the history > is complex here, so I don't think we should ask anyone to rewrite things > further, though in general it would be nicer to have separate proposals > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the > changes to imports (which as Joachim points out raise issues). > > I'm a bit concerned that the proposal does not motivate or specify > -Wpattern-namespace-qualified very well. > > > On 08/12/2022 08:33, Joachim Breitner wrote: >> ... >> >> This gives us (at least) these options: >> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, >> introduce one or two new extensions for the newer changes. >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >> disregarding issue #551. >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >> arguing that GHC20xx allows more liberal (backward-compatibile) >> changes than, say, Haskell2010 would allow. >> >> Certainly 1 is the least bold move. I am not sure what the best way >> forwards is, and welcome other opinions. > > I would prefer a variant of 1: allow "data" as a keyword in import lists > under ExplicitNamespaces, but make the other changes under other > extensions. > > As I've said previously, I have a general preference for multiple small, > orthogonal extensions rather than changing existing extensions to add > unrelated features that happen to be in similar territory. I realise > this is controversial, of course. > > Cheers, > > Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
On 12/12/2022 16:50, Chris Dornan wrote:
I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go.
I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces.
I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case.
Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly.
This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features! I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions? Adam
On 12 Dec 2022, at 12:21, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote:
On 12/12/2022 11:39, Simon Peyton Jones wrote:
{-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above.
The nested use is already possible with ExplicitNamespaces. Currently it allows
import M (T(type MkT)) import M (type MkT) import M (pattern MkT)
whereas the proposal extends it to add the possibility to write
import M type (MkT) import M data (MkT) import M (data MkT)
In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>>. It only covers import M *type * import M *data *as MD where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal?
I'm trying to understand what
import M type (MkT)
means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing
import M (T(type MkT))
which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>).
I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something?
Cheers,
Adam
On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>> wrote: Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>> I realised I'm unclear how the proposed extensions to ExplicitNamespaces are supposed to work. The existing situation is apparently that for a (non-punned) data constructor, it is possible to use either a pattern or type qualifier in an import list (presumably because DataKinds means the constructor is in scope at both the term and type levels), and the imported constructor is then usable in both contexts. For example, the following is accepted at present: module M where data T = MkT {-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level The present proposal says "With type specified in the import, only identifiers belonging to the type namespace will be brought into the scope." I'm not exactly sure how to interpret this, does it mean the following alternative will be accepted or rejected? module N where import M type (MkT) v = MkT I'm worried we will end up with a situation where ExplicitNamespaces does subtly different things depending on the position of the keyword. In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Given the discussion about exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus separate extensions, perhaps we should accept the parts relating to -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be proposed separately? Cheers, Adam On 09/12/2022 11:11, Adam Gundry wrote: > I'm broadly in favour of accepting the proposal. I realise the history > is complex here, so I don't think we should ask anyone to rewrite things > further, though in general it would be nicer to have separate proposals > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the > changes to imports (which as Joachim points out raise issues). > > I'm a bit concerned that the proposal does not motivate or specify > -Wpattern-namespace-qualified very well. > > > On 08/12/2022 08:33, Joachim Breitner wrote: >> ... >> >> This gives us (at least) these options: >> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, >> introduce one or two new extensions for the newer changes. >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >> disregarding issue #551. >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >> arguing that GHC20xx allows more liberal (backward-compatibile) >> changes than, say, Haskell2010 would allow. >> >> Certainly 1 is the least bold move. I am not sure what the best way >> forwards is, and welcome other opinions. > > I would prefer a variant of 1: allow "data" as a keyword in import lists > under ExplicitNamespaces, but make the other changes under other > extensions. > > As I've said previously, I have a general preference for multiple small, > orthogonal extensions rather than changing existing extensions to add > unrelated features that happen to be in similar territory. I realise > this is controversial, of course. > > Cheers, > > Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view. It sounds like we are in strong agreement. Chris
On 12 Dec 2022, at 20:11, Adam Gundry <adam@well-typed.com> wrote:
On 12/12/2022 16:50, Chris Dornan wrote:
I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly.
This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features!
I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions?
Adam
On 12 Dec 2022, at 12:21, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote:
On 12/12/2022 11:39, Simon Peyton Jones wrote:
{-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above.
The nested use is already possible with ExplicitNamespaces. Currently it allows
import M (T(type MkT)) import M (type MkT) import M (pattern MkT)
whereas the proposal extends it to add the possibility to write
import M type (MkT) import M data (MkT) import M (data MkT)
In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>>. It only covers import M *type * import M *data *as MD where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal?
I'm trying to understand what
import M type (MkT)
means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing
import M (T(type MkT))
which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>).
I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something?
Cheers,
Adam
On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>> wrote: Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>> I realised I'm unclear how the proposed extensions to ExplicitNamespaces are supposed to work. The existing situation is apparently that for a (non-punned) data constructor, it is possible to use either a pattern or type qualifier in an import list (presumably because DataKinds means the constructor is in scope at both the term and type levels), and the imported constructor is then usable in both contexts. For example, the following is accepted at present: module M where data T = MkT {-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level The present proposal says "With type specified in the import, only identifiers belonging to the type namespace will be brought into the scope." I'm not exactly sure how to interpret this, does it mean the following alternative will be accepted or rejected? module N where import M type (MkT) v = MkT I'm worried we will end up with a situation where ExplicitNamespaces does subtly different things depending on the position of the keyword. In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Given the discussion about exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus separate extensions, perhaps we should accept the parts relating to -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be proposed separately? Cheers, Adam On 09/12/2022 11:11, Adam Gundry wrote: > I'm broadly in favour of accepting the proposal. I realise the history > is complex here, so I don't think we should ask anyone to rewrite things > further, though in general it would be nicer to have separate proposals > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the > changes to imports (which as Joachim points out raise issues). > > I'm a bit concerned that the proposal does not motivate or specify > -Wpattern-namespace-qualified very well. > > > On 08/12/2022 08:33, Joachim Breitner wrote: >> ... >> >> This gives us (at least) these options: >> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, >> introduce one or two new extensions for the newer changes. >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >> disregarding issue #551. >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >> arguing that GHC20xx allows more liberal (backward-compatibile) >> changes than, say, Haskell2010 would allow. >> >> Certainly 1 is the least bold move. I am not sure what the best way >> forwards is, and welcome other opinions. > > I would prefer a variant of 1: allow "data" as a keyword in import lists > under ExplicitNamespaces, but make the other changes under other > extensions. > > As I've said previously, I have a general preference for multiple small, > orthogonal extensions rather than changing existing extensions to add > unrelated features that happen to be in similar territory. I realise > this is controversial, of course. > > Cheers, > > Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal. I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it. Simon On Mon, 12 Dec 2022 at 22:05, Chris Dornan <chris@chrisdornan.com> wrote:
In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view.
It sounds like we are in strong agreement.
Chris
On 12 Dec 2022, at 20:11, Adam Gundry <adam@well-typed.com> wrote:
On 12/12/2022 16:50, Chris Dornan wrote:
I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly.
This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features!
I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions?
Adam
On 12 Dec 2022, at 12:21, Adam Gundry <adam@well-typed.com <mailto: adam@well-typed.com>> wrote:
On 12/12/2022 11:39, Simon Peyton Jones wrote:
{-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data
constructor
v = MkT -- usage at term level Crumbs. I had
not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above.
The nested use is already possible with ExplicitNamespaces. Currently it allows
import M (T(type MkT)) import M (type MkT) import M (pattern MkT)
whereas the proposal extends it to add the possibility to write
import M type (MkT) import M data (MkT) import M (data MkT)
In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec < https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... < https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>>. It only covers import M *type * import M *data *as MD where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal?
I'm trying to understand what
import M type (MkT)
means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing
import M (T(type MkT))
which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 < https://gitlab.haskell.org/ghc/ghc/-/issues/22581>).
I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something?
Cheers,
Adam
On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto: adam@well-typed.com>>> wrote: Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 < https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 < https://gitlab.haskell.org/ghc/ghc/-/issues/22581>> I realised I'm unclear how the proposed extensions to ExplicitNamespaces are supposed to work. The existing situation is apparently that for a (non-punned) data constructor, it is possible to use either a pattern or type qualifier in an import list (presumably because DataKinds means the constructor is in scope at both the term and type levels), and the imported constructor is then usable in both contexts. For example, the following is accepted at present: module M where data T = MkT {-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level The present proposal says "With type specified in the import, only identifiers belonging to the type namespace will be brought into the scope." I'm not exactly sure how to interpret this, does it mean the following alternative will be accepted or rejected? module N where import M type (MkT) v = MkT I'm worried we will end up with a situation where ExplicitNamespaces does subtly different things depending on the position of the keyword. In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Given the discussion about exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus separate extensions, perhaps we should accept the parts relating to -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be proposed separately? Cheers, Adam On 09/12/2022 11:11, Adam Gundry wrote: > I'm broadly in favour of accepting the proposal. I realise the history > is complex here, so I don't think we should ask anyone to rewrite things > further, though in general it would be nicer to have separate proposals > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the > changes to imports (which as Joachim points out raise issues). > > I'm a bit concerned that the proposal does not motivate or specify > -Wpattern-namespace-qualified very well. > > > On 08/12/2022 08:33, Joachim Breitner wrote: >> ... >> >> This gives us (at least) these options: >> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, >> introduce one or two new extensions for the newer changes. >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >> disregarding issue #551. >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >> arguing that GHC20xx allows more liberal (backward-compatibile) >> changes than, say, Haskell2010 would allow. >> >> Certainly 1 is the least bold move. I am not sure what the best way >> forwards is, and welcome other opinions. > > I would prefer a variant of 1: allow "data" as a keyword in import lists > under ExplicitNamespaces, but make the other changes under other > extensions. > > As I've said previously, I have a general preference for multiple small, > orthogonal extensions rather than changing existing extensions to add > unrelated features that happen to be in similar territory. I realise > this is controversial, of course. > > Cheers, > > Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Although the two aspects of the proposal were motivated by the same problem they are doing completely different things. As long as it was easier to deal with them together the path of least resistance was to keep them bundled up, but it is becoming ever clearer that they are tied up in divergent organisational as well as technical concerns. The warnings are well understood and ready to go with a patch whereas, as this thread illustrates, nobody seems to properly understand what is going on with ExplicitNameSpaces; we are still confident that we can sort it all out and confident that we want to sort it all out but still there is work to be done. Added to this there is the fact that the problems with namespaces are entirely inherited from an existing extension that is poorly documented and, as we have just discovered, poorly understood. For all the reasons explained in the proposal we are likely to be leaning more heavily on ExplicitNameSpaces as we develop DH so we really need sort out what it does and get it written down. Here is the kicker — when we do sort out ExplicitNameSpaces and write it up properly we are going to want it attached to language extension dedicated to managing ExplicitNameSpaces, not an extension bundled up with some enabled warnings. I am happy to work with Artyom to get the new proposal set up etc. Chris
On 13 Dec 2022, at 09:01, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal.
I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it.
Simon
On Mon, 12 Dec 2022 at 22:05, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote: In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view.
It sounds like we are in strong agreement.
Chris
On 12 Dec 2022, at 20:11, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote:
On 12/12/2022 16:50, Chris Dornan wrote:
I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly.
This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features!
I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions?
Adam
On 12 Dec 2022, at 12:21, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>> wrote:
On 12/12/2022 11:39, Simon Peyton Jones wrote:
{-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above.
The nested use is already possible with ExplicitNamespaces. Currently it allows
import M (T(type MkT)) import M (type MkT) import M (pattern MkT)
whereas the proposal extends it to add the possibility to write
import M type (MkT) import M data (MkT) import M (data MkT)
In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification> <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>>>. It only covers import M *type * import M *data *as MD where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal?
I'm trying to understand what
import M type (MkT)
means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing
import M (T(type MkT))
which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>>).
I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something?
Cheers,
Adam
On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>> <mailto:adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>>> wrote: Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>>> I realised I'm unclear how the proposed extensions to ExplicitNamespaces are supposed to work. The existing situation is apparently that for a (non-punned) data constructor, it is possible to use either a pattern or type qualifier in an import list (presumably because DataKinds means the constructor is in scope at both the term and type levels), and the imported constructor is then usable in both contexts. For example, the following is accepted at present: module M where data T = MkT {-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level The present proposal says "With type specified in the import, only identifiers belonging to the type namespace will be brought into the scope." I'm not exactly sure how to interpret this, does it mean the following alternative will be accepted or rejected? module N where import M type (MkT) v = MkT I'm worried we will end up with a situation where ExplicitNamespaces does subtly different things depending on the position of the keyword. In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Given the discussion about exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus separate extensions, perhaps we should accept the parts relating to -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be proposed separately? Cheers, Adam On 09/12/2022 11:11, Adam Gundry wrote: > I'm broadly in favour of accepting the proposal. I realise the history > is complex here, so I don't think we should ask anyone to rewrite things > further, though in general it would be nicer to have separate proposals > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the > changes to imports (which as Joachim points out raise issues). > > I'm a bit concerned that the proposal does not motivate or specify > -Wpattern-namespace-qualified very well. > > > On 08/12/2022 08:33, Joachim Breitner wrote: >> ... >> >> This gives us (at least) these options: >> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, >> introduce one or two new extensions for the newer changes. >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >> disregarding issue #551. >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >> arguing that GHC20xx allows more liberal (backward-compatibile) >> changes than, say, Haskell2010 would allow. >> >> Certainly 1 is the least bold move. I am not sure what the best way >> forwards is, and welcome other opinions. > > I would prefer a variant of 1: allow "data" as a keyword in import lists > under ExplicitNamespaces, but make the other changes under other > extensions. > > As I've said previously, I have a general preference for multiple small, > orthogonal extensions rather than changing existing extensions to add > unrelated features that happen to be in similar territory. I realise > this is controversial, of course. > > Cheers, > > Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ <https://www.well-typed.com/>
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
I strongly oppose requesting that the proposal be split. I agree that the two parts of the proposal can notionally be separated. But sometimes I feel that, in the face of difficult decisions, this committee has punted by requesting formatting changes of proposals. My case in point is around #448 about scoped type variables. That proposal arose out of a smattering of other proposals... but the committee deemed that the other proposals were too separate and needed to be considered as a whole. So, with some effort, I put them all in one. Then members of the committee said that the proposal was too big and to break it up! I refused, and had to hold my ground despite several requests. In the end, half was accepted, and at that point I took the other half and re-proposed it. I actually don't mind that last part -- I think partial acceptance is a reasonable action. But the formatting and reformatting is quite a bit of work, and I'm not convinced it really helped our debate. I'm worried we're repeating this here. Richard
On Dec 13, 2022, at 10:50 AM, Chris Dornan <chris@chrisdornan.com> wrote:
Although the two aspects of the proposal were motivated by the same problem they are doing completely different things. As long as it was easier to deal with them together the path of least resistance was to keep them bundled up, but it is becoming ever clearer that they are tied up in divergent organisational as well as technical concerns. The warnings are well understood and ready to go with a patch whereas, as this thread illustrates, nobody seems to properly understand what is going on with ExplicitNameSpaces; we are still confident that we can sort it all out and confident that we want to sort it all out but still there is work to be done.
Added to this there is the fact that the problems with namespaces are entirely inherited from an existing extension that is poorly documented and, as we have just discovered, poorly understood. For all the reasons explained in the proposal we are likely to be leaning more heavily on ExplicitNameSpaces as we develop DH so we really need sort out what it does and get it written down. Here is the kicker — when we do sort out ExplicitNameSpaces and write it up properly we are going to want it attached to language extension dedicated to managing ExplicitNameSpaces, not an extension bundled up with some enabled warnings.
I am happy to work with Artyom to get the new proposal set up etc.
Chris
On 13 Dec 2022, at 09:01, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal.
I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it.
Simon
On Mon, 12 Dec 2022 at 22:05, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote: In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view.
It sounds like we are in strong agreement.
Chris
On 12 Dec 2022, at 20:11, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote:
On 12/12/2022 16:50, Chris Dornan wrote:
I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly.
This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features!
I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions?
Adam
On 12 Dec 2022, at 12:21, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>> wrote:
On 12/12/2022 11:39, Simon Peyton Jones wrote:
{-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above.
The nested use is already possible with ExplicitNamespaces. Currently it allows
import M (T(type MkT)) import M (type MkT) import M (pattern MkT)
whereas the proposal extends it to add the possibility to write
import M type (MkT) import M data (MkT) import M (data MkT)
In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification> <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>>>. It only covers import M *type * import M *data *as MD where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal?
I'm trying to understand what
import M type (MkT)
means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing
import M (T(type MkT))
which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>>).
I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something?
Cheers,
Adam
On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>> <mailto:adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>>> wrote: Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>>> I realised I'm unclear how the proposed extensions to ExplicitNamespaces are supposed to work. The existing situation is apparently that for a (non-punned) data constructor, it is possible to use either a pattern or type qualifier in an import list (presumably because DataKinds means the constructor is in scope at both the term and type levels), and the imported constructor is then usable in both contexts. For example, the following is accepted at present: module M where data T = MkT {-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level The present proposal says "With type specified in the import, only identifiers belonging to the type namespace will be brought into the scope." I'm not exactly sure how to interpret this, does it mean the following alternative will be accepted or rejected? module N where import M type (MkT) v = MkT I'm worried we will end up with a situation where ExplicitNamespaces does subtly different things depending on the position of the keyword. In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Given the discussion about exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus separate extensions, perhaps we should accept the parts relating to -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be proposed separately? Cheers, Adam On 09/12/2022 11:11, Adam Gundry wrote: > I'm broadly in favour of accepting the proposal. I realise the history > is complex here, so I don't think we should ask anyone to rewrite things > further, though in general it would be nicer to have separate proposals > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the > changes to imports (which as Joachim points out raise issues). > > I'm a bit concerned that the proposal does not motivate or specify > -Wpattern-namespace-qualified very well. > > > On 08/12/2022 08:33, Joachim Breitner wrote: >> ... >> >> This gives us (at least) these options: >> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, >> introduce one or two new extensions for the newer changes. >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >> disregarding issue #551. >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >> arguing that GHC20xx allows more liberal (backward-compatibile) >> changes than, say, Haskell2010 would allow. >> >> Certainly 1 is the least bold move. I am not sure what the best way >> forwards is, and welcome other opinions. > > I would prefer a variant of 1: allow "data" as a keyword in import lists > under ExplicitNamespaces, but make the other changes under other > extensions. > > As I've said previously, I have a general preference for multiple small, > orthogonal extensions rather than changing existing extensions to add > unrelated features that happen to be in similar territory. I realise > this is controversial, of course. > > Cheers, > > Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ <https://www.well-typed.com/>
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
For reasons I have made entirely clear I _strongly_ desire this split — are you offering to take over shepherding this proposal Richard? Because I am now totally stymied and unable to manage the process.
On 15 Dec 2022, at 00:47, Richard Eisenberg <lists@richarde.dev> wrote:
I strongly oppose requesting that the proposal be split. I agree that the two parts of the proposal can notionally be separated. But sometimes I feel that, in the face of difficult decisions, this committee has punted by requesting formatting changes of proposals. My case in point is around #448 about scoped type variables. That proposal arose out of a smattering of other proposals... but the committee deemed that the other proposals were too separate and needed to be considered as a whole. So, with some effort, I put them all in one. Then members of the committee said that the proposal was too big and to break it up! I refused, and had to hold my ground despite several requests. In the end, half was accepted, and at that point I took the other half and re-proposed it. I actually don't mind that last part -- I think partial acceptance is a reasonable action. But the formatting and reformatting is quite a bit of work, and I'm not convinced it really helped our debate. I'm worried we're repeating this here.
Richard
On Dec 13, 2022, at 10:50 AM, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote:
Although the two aspects of the proposal were motivated by the same problem they are doing completely different things. As long as it was easier to deal with them together the path of least resistance was to keep them bundled up, but it is becoming ever clearer that they are tied up in divergent organisational as well as technical concerns. The warnings are well understood and ready to go with a patch whereas, as this thread illustrates, nobody seems to properly understand what is going on with ExplicitNameSpaces; we are still confident that we can sort it all out and confident that we want to sort it all out but still there is work to be done.
Added to this there is the fact that the problems with namespaces are entirely inherited from an existing extension that is poorly documented and, as we have just discovered, poorly understood. For all the reasons explained in the proposal we are likely to be leaning more heavily on ExplicitNameSpaces as we develop DH so we really need sort out what it does and get it written down. Here is the kicker — when we do sort out ExplicitNameSpaces and write it up properly we are going to want it attached to language extension dedicated to managing ExplicitNameSpaces, not an extension bundled up with some enabled warnings.
I am happy to work with Artyom to get the new proposal set up etc.
Chris
On 13 Dec 2022, at 09:01, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal.
I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it.
Simon
On Mon, 12 Dec 2022 at 22:05, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote: In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view.
It sounds like we are in strong agreement.
Chris
On 12 Dec 2022, at 20:11, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote:
On 12/12/2022 16:50, Chris Dornan wrote:
I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly.
This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features!
I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions?
Adam
On 12 Dec 2022, at 12:21, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>> wrote:
On 12/12/2022 11:39, Simon Peyton Jones wrote: > {-# LANGUAGE ExplicitNamespaces #-} > module N where > import M (T(type MkT)) -- NB "type" import of a data constructor > v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above.
The nested use is already possible with ExplicitNamespaces. Currently it allows
import M (T(type MkT)) import M (type MkT) import M (pattern MkT)
whereas the proposal extends it to add the possibility to write
import M type (MkT) import M data (MkT) import M (data MkT)
> In general, I don't feel the extensions to ExplicitNamespaces included > in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification> <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>>>. It only covers > import M *type * > import M *data *as MD > where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal?
I'm trying to understand what
import M type (MkT)
means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing
import M (T(type MkT))
which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>>).
I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something?
Cheers,
Adam
> On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>> <mailto:adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>>> wrote: > Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>> > <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>>> I > realised I'm unclear how the proposed extensions to ExplicitNamespaces > are supposed to work. The existing situation is apparently that for a > (non-punned) data constructor, it is possible to use either a > pattern or > type qualifier in an import list (presumably because DataKinds means > the > constructor is in scope at both the term and type levels), and the > imported constructor is then usable in both contexts. > For example, the following is accepted at present: > module M where > data T = MkT > {-# LANGUAGE ExplicitNamespaces #-} > module N where > import M (T(type MkT)) -- NB "type" import of a data constructor > v = MkT -- usage at term level > The present proposal says "With type specified in the import, only > identifiers belonging to the type namespace will be brought into the > scope." I'm not exactly sure how to interpret this, does it mean the > following alternative will be accepted or rejected? > module N where > import M type (MkT) > v = MkT > I'm worried we will end up with a situation where ExplicitNamespaces > does subtly different things depending on the position of the keyword. > In general, I don't feel the extensions to ExplicitNamespaces included > in the proposal are very clearly specified. Given the discussion about > exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus > separate extensions, perhaps we should accept the parts relating to > -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be > proposed separately? > Cheers, > Adam > On 09/12/2022 11:11, Adam Gundry wrote: > > I'm broadly in favour of accepting the proposal. I realise the > history > > is complex here, so I don't think we should ask anyone to rewrite > things > > further, though in general it would be nicer to have separate > proposals > > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the > > changes to imports (which as Joachim points out raise issues). > > > > I'm a bit concerned that the proposal does not motivate or specify > > -Wpattern-namespace-qualified very well. > > > > > > On 08/12/2022 08:33, Joachim Breitner wrote: > >> ... > >> > >> This gives us (at least) these options: > >> > >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to > GHC2023, > >> introduce one or two new extensions for the newer changes. > >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, > >> disregarding issue #551. > >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, > >> arguing that GHC20xx allows more liberal (backward-compatibile) > >> changes than, say, Haskell2010 would allow. > >> > >> Certainly 1 is the least bold move. I am not sure what the best way > >> forwards is, and welcome other opinions. > > > > I would prefer a variant of 1: allow "data" as a keyword in > import lists > > under ExplicitNamespaces, but make the other changes under other > > extensions. > > > > As I've said previously, I have a general preference for multiple > small, > > orthogonal extensions rather than changing existing extensions to > add > > unrelated features that happen to be in similar territory. I realise > > this is controversial, of course. > > > > Cheers, > > > > Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ <https://www.well-typed.com/>
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
I recommend acceptance as-is. I see no difficulty with the namespace part of the proposal. Yes, the *existing *namespace extension is ill specified. But this proposal does not make that situation worse (the delta is clearly specified), and it seems unfair of us to penalise this proposal because of the pre-existing situation. Of course, it would be better still to have a new, subsequent proposal that clarifies the ExplicitNameSpaceProposal. Perhaps we could invite Artyom write it, as a favour to the community. Or perhaps a member of the committee might like to. Simon On Thu, 15 Dec 2022 at 00:55, Chris Dornan <chris@chrisdornan.com> wrote:
For reasons I have made entirely clear I _strongly_ desire this split — are you offering to take over shepherding this proposal Richard? Because I am now totally stymied and unable to manage the process.
On 15 Dec 2022, at 00:47, Richard Eisenberg <lists@richarde.dev> wrote:
I strongly oppose requesting that the proposal be split. I agree that the two parts of the proposal can notionally be separated. But sometimes I feel that, in the face of difficult decisions, this committee has punted by requesting formatting changes of proposals. My case in point is around #448 about scoped type variables. That proposal arose out of a smattering of other proposals... but the committee deemed that the other proposals were too separate and needed to be considered as a whole. So, with some effort, I put them all in one. Then members of the committee said that the proposal was too big and to break it up! I refused, and had to hold my ground despite several requests. In the end, half was accepted, and at that point I took the other half and re-proposed it. I actually don't mind that last part -- I think partial acceptance is a reasonable action. But the formatting and reformatting is quite a bit of work, and I'm not convinced it really helped our debate. I'm worried we're repeating this here.
Richard
On Dec 13, 2022, at 10:50 AM, Chris Dornan <chris@chrisdornan.com> wrote:
Although the two aspects of the proposal were motivated by the same problem they are doing completely different things. As long as it was easier to deal with them together the path of least resistance was to keep them bundled up, but it is becoming ever clearer that they are tied up in divergent organisational as well as technical concerns. The warnings are well understood and ready to go with a patch whereas, as this thread illustrates, nobody seems to properly understand what is going on with ExplicitNameSpaces; we are still confident that we can sort it all out and confident that we want to sort it all out but still there is work to be done.
Added to this there is the fact that the problems with namespaces are entirely inherited from an existing extension that is poorly documented and, as we have just discovered, poorly understood. For all the reasons explained in the proposal we are likely to be leaning more heavily on ExplicitNameSpaces as we develop DH so we really need sort out what it does and get it written down. Here is the kicker — when we do sort out ExplicitNameSpaces and write it up properly we are going to want it attached to language extension dedicated to managing ExplicitNameSpaces, not an extension bundled up with some enabled warnings.
I am happy to work with Artyom to get the new proposal set up etc.
Chris
On 13 Dec 2022, at 09:01, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal.
I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it.
Simon
On Mon, 12 Dec 2022 at 22:05, Chris Dornan <chris@chrisdornan.com> wrote:
In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view.
It sounds like we are in strong agreement.
Chris
On 12 Dec 2022, at 20:11, Adam Gundry <adam@well-typed.com> wrote:
On 12/12/2022 16:50, Chris Dornan wrote:
I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly.
This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features!
I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions?
Adam
On 12 Dec 2022, at 12:21, Adam Gundry <adam@well-typed.com <mailto: adam@well-typed.com>> wrote:
On 12/12/2022 11:39, Simon Peyton Jones wrote:
{-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data
constructor
v = MkT -- usage at term level Crumbs. I
had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above.
The nested use is already possible with ExplicitNamespaces. Currently it allows
import M (T(type MkT)) import M (type MkT) import M (pattern MkT)
whereas the proposal extends it to add the possibility to write
import M type (MkT) import M data (MkT) import M (data MkT)
In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec < https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... < https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>>. It only covers import M *type * import M *data *as MD where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal?
I'm trying to understand what
import M type (MkT)
means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing
import M (T(type MkT))
which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 < https://gitlab.haskell.org/ghc/ghc/-/issues/22581>).
I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something?
Cheers,
Adam
On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto: adam@well-typed.com>>> wrote: Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 < https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 < https://gitlab.haskell.org/ghc/ghc/-/issues/22581>> I realised I'm unclear how the proposed extensions to ExplicitNamespaces are supposed to work. The existing situation is apparently that for a (non-punned) data constructor, it is possible to use either a pattern or type qualifier in an import list (presumably because DataKinds means the constructor is in scope at both the term and type levels), and the imported constructor is then usable in both contexts. For example, the following is accepted at present: module M where data T = MkT {-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level The present proposal says "With type specified in the import, only identifiers belonging to the type namespace will be brought into the scope." I'm not exactly sure how to interpret this, does it mean the following alternative will be accepted or rejected? module N where import M type (MkT) v = MkT I'm worried we will end up with a situation where ExplicitNamespaces does subtly different things depending on the position of the keyword. In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Given the discussion about exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus separate extensions, perhaps we should accept the parts relating to -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be proposed separately? Cheers, Adam On 09/12/2022 11:11, Adam Gundry wrote: > I'm broadly in favour of accepting the proposal. I realise the history > is complex here, so I don't think we should ask anyone to rewrite things > further, though in general it would be nicer to have separate proposals > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the > changes to imports (which as Joachim points out raise issues). > > I'm a bit concerned that the proposal does not motivate or specify > -Wpattern-namespace-qualified very well. > > > On 08/12/2022 08:33, Joachim Breitner wrote: >> ... >> >> This gives us (at least) these options: >> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, >> introduce one or two new extensions for the newer changes. >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >> disregarding issue #551. >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >> arguing that GHC20xx allows more liberal (backward-compatibile) >> changes than, say, Haskell2010 would allow. >> >> Certainly 1 is the least bold move. I am not sure what the best way >> forwards is, and welcome other opinions. > > I would prefer a variant of 1: allow "data" as a keyword in import lists > under ExplicitNamespaces, but make the other changes under other > extensions. > > As I've said previously, I have a general preference for multiple small, > orthogonal extensions rather than changing existing extensions to add > unrelated features that happen to be in similar territory. I realise > this is controversial, of course. > > Cheers, > > Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
I am so tempted to take this up — it just gets us right out of the doom loop that seems to be dogging this proposal, which I have come to think is incredibly valuable, as much for the analysis and insight the proposal has generated as for tools it proposes. My only reservation is that I think it somewhat suboptimal to couple such diverse mechanisms as the warnings and import name spaces. However, if we do the follow up then we can recast the extension as primarily about warning and implying thew new cleaned-up namespace extension. So the pragmatist in me says yes, let’s do it, provided the rest of the committee is OK with that. If so I will organise the follow up — I will invite Artyom and, of course, I would love any input I can get from Adam and Richard and anyone else on the committee or elsewhere. (Getting Adam onto the committee was a major coup in my opinion — but I knew that already from elsewhere.) In general I think it would be good if we could establish a precedent where the appointed shepherd is trusted to manage the process. Here we can see how multiple inputs into the managerial process are leading to compromises that could be compromising the technical outcome, just to escape ourselves (we hope it all work out in the end, of course). When it comes to technical matters, of course, everyone must have a veto but for organisational matters I think things will go much better if each person appointed to manage the process is left to it, unless a serious problem is seen, in which case a “have you considered this” would probably be in order. Chris
On 15 Dec 2022, at 08:14, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
I recommend acceptance as-is.
I see no difficulty with the namespace part of the proposal. Yes, the existing namespace extension is ill specified. But this proposal does not make that situation worse (the delta is clearly specified), and it seems unfair of us to penalise this proposal because of the pre-existing situation.
Of course, it would be better still to have a new, subsequent proposal that clarifies the ExplicitNameSpaceProposal. Perhaps we could invite Artyom write it, as a favour to the community. Or perhaps a member of the committee might like to.
Simon
On Thu, 15 Dec 2022 at 00:55, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote: For reasons I have made entirely clear I _strongly_ desire this split — are you offering to take over shepherding this proposal Richard? Because I am now totally stymied and unable to manage the process.
On 15 Dec 2022, at 00:47, Richard Eisenberg <lists@richarde.dev <mailto:lists@richarde.dev>> wrote:
I strongly oppose requesting that the proposal be split. I agree that the two parts of the proposal can notionally be separated. But sometimes I feel that, in the face of difficult decisions, this committee has punted by requesting formatting changes of proposals. My case in point is around #448 about scoped type variables. That proposal arose out of a smattering of other proposals... but the committee deemed that the other proposals were too separate and needed to be considered as a whole. So, with some effort, I put them all in one. Then members of the committee said that the proposal was too big and to break it up! I refused, and had to hold my ground despite several requests. In the end, half was accepted, and at that point I took the other half and re-proposed it. I actually don't mind that last part -- I think partial acceptance is a reasonable action. But the formatting and reformatting is quite a bit of work, and I'm not convinced it really helped our debate. I'm worried we're repeating this here.
Richard
On Dec 13, 2022, at 10:50 AM, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote:
Although the two aspects of the proposal were motivated by the same problem they are doing completely different things. As long as it was easier to deal with them together the path of least resistance was to keep them bundled up, but it is becoming ever clearer that they are tied up in divergent organisational as well as technical concerns. The warnings are well understood and ready to go with a patch whereas, as this thread illustrates, nobody seems to properly understand what is going on with ExplicitNameSpaces; we are still confident that we can sort it all out and confident that we want to sort it all out but still there is work to be done.
Added to this there is the fact that the problems with namespaces are entirely inherited from an existing extension that is poorly documented and, as we have just discovered, poorly understood. For all the reasons explained in the proposal we are likely to be leaning more heavily on ExplicitNameSpaces as we develop DH so we really need sort out what it does and get it written down. Here is the kicker — when we do sort out ExplicitNameSpaces and write it up properly we are going to want it attached to language extension dedicated to managing ExplicitNameSpaces, not an extension bundled up with some enabled warnings.
I am happy to work with Artyom to get the new proposal set up etc.
Chris
On 13 Dec 2022, at 09:01, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal.
I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it.
Simon
On Mon, 12 Dec 2022 at 22:05, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote: In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view.
It sounds like we are in strong agreement.
Chris
On 12 Dec 2022, at 20:11, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote:
On 12/12/2022 16:50, Chris Dornan wrote:
I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly.
This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features!
I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions?
Adam
> On 12 Dec 2022, at 12:21, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>> wrote: > > On 12/12/2022 11:39, Simon Peyton Jones wrote: >> {-# LANGUAGE ExplicitNamespaces #-} >> module N where >> import M (T(type MkT)) -- NB "type" import of a data constructor >> v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above. > > The nested use is already possible with ExplicitNamespaces. Currently it allows > > import M (T(type MkT)) > import M (type MkT) > import M (pattern MkT) > > whereas the proposal extends it to add the possibility to write > > import M type (MkT) > import M data (MkT) > import M (data MkT) > > >> In general, I don't feel the extensions to ExplicitNamespaces included >> in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification> <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>>>. It only covers >> import M *type * >> import M *data *as MD >> where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal? > > I'm trying to understand what > > import M type (MkT) > > means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing > > import M (T(type MkT)) > > which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>>). > > I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something? > > Cheers, > > Adam > > >> On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>> <mailto:adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>>> wrote: >> Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>> >> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>>> I >> realised I'm unclear how the proposed extensions to ExplicitNamespaces >> are supposed to work. The existing situation is apparently that for a >> (non-punned) data constructor, it is possible to use either a >> pattern or >> type qualifier in an import list (presumably because DataKinds means >> the >> constructor is in scope at both the term and type levels), and the >> imported constructor is then usable in both contexts. >> For example, the following is accepted at present: >> module M where >> data T = MkT >> {-# LANGUAGE ExplicitNamespaces #-} >> module N where >> import M (T(type MkT)) -- NB "type" import of a data constructor >> v = MkT -- usage at term level >> The present proposal says "With type specified in the import, only >> identifiers belonging to the type namespace will be brought into the >> scope." I'm not exactly sure how to interpret this, does it mean the >> following alternative will be accepted or rejected? >> module N where >> import M type (MkT) >> v = MkT >> I'm worried we will end up with a situation where ExplicitNamespaces >> does subtly different things depending on the position of the keyword. >> In general, I don't feel the extensions to ExplicitNamespaces included >> in the proposal are very clearly specified. Given the discussion about >> exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus >> separate extensions, perhaps we should accept the parts relating to >> -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be >> proposed separately? >> Cheers, >> Adam >> On 09/12/2022 11:11, Adam Gundry wrote: >> > I'm broadly in favour of accepting the proposal. I realise the >> history >> > is complex here, so I don't think we should ask anyone to rewrite >> things >> > further, though in general it would be nicer to have separate >> proposals >> > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the >> > changes to imports (which as Joachim points out raise issues). >> > >> > I'm a bit concerned that the proposal does not motivate or specify >> > -Wpattern-namespace-qualified very well. >> > >> > >> > On 08/12/2022 08:33, Joachim Breitner wrote: >> >> ... >> >> >> >> This gives us (at least) these options: >> >> >> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to >> GHC2023, >> >> introduce one or two new extensions for the newer changes. >> >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >> >> disregarding issue #551. >> >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >> >> arguing that GHC20xx allows more liberal (backward-compatibile) >> >> changes than, say, Haskell2010 would allow. >> >> >> >> Certainly 1 is the least bold move. I am not sure what the best way >> >> forwards is, and welcome other opinions. >> > >> > I would prefer a variant of 1: allow "data" as a keyword in >> import lists >> > under ExplicitNamespaces, but make the other changes under other >> > extensions. >> > >> > As I've said previously, I have a general preference for multiple >> small, >> > orthogonal extensions rather than changing existing extensions to >> add >> > unrelated features that happen to be in similar territory. I realise >> > this is controversial, of course. >> > >> > Cheers, >> > >> > Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ <https://www.well-typed.com/>
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
Does anybody object to us accepting #270 now? Speak now, etc.
On 15 Dec 2022, at 08:14, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
I recommend acceptance as-is.
I see no difficulty with the namespace part of the proposal. Yes, the existing namespace extension is ill specified. But this proposal does not make that situation worse (the delta is clearly specified), and it seems unfair of us to penalise this proposal because of the pre-existing situation.
Of course, it would be better still to have a new, subsequent proposal that clarifies the ExplicitNameSpaceProposal. Perhaps we could invite Artyom write it, as a favour to the community. Or perhaps a member of the committee might like to.
Simon
On Thu, 15 Dec 2022 at 00:55, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote: For reasons I have made entirely clear I _strongly_ desire this split — are you offering to take over shepherding this proposal Richard? Because I am now totally stymied and unable to manage the process.
On 15 Dec 2022, at 00:47, Richard Eisenberg <lists@richarde.dev <mailto:lists@richarde.dev>> wrote:
I strongly oppose requesting that the proposal be split. I agree that the two parts of the proposal can notionally be separated. But sometimes I feel that, in the face of difficult decisions, this committee has punted by requesting formatting changes of proposals. My case in point is around #448 about scoped type variables. That proposal arose out of a smattering of other proposals... but the committee deemed that the other proposals were too separate and needed to be considered as a whole. So, with some effort, I put them all in one. Then members of the committee said that the proposal was too big and to break it up! I refused, and had to hold my ground despite several requests. In the end, half was accepted, and at that point I took the other half and re-proposed it. I actually don't mind that last part -- I think partial acceptance is a reasonable action. But the formatting and reformatting is quite a bit of work, and I'm not convinced it really helped our debate. I'm worried we're repeating this here.
Richard
On Dec 13, 2022, at 10:50 AM, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote:
Although the two aspects of the proposal were motivated by the same problem they are doing completely different things. As long as it was easier to deal with them together the path of least resistance was to keep them bundled up, but it is becoming ever clearer that they are tied up in divergent organisational as well as technical concerns. The warnings are well understood and ready to go with a patch whereas, as this thread illustrates, nobody seems to properly understand what is going on with ExplicitNameSpaces; we are still confident that we can sort it all out and confident that we want to sort it all out but still there is work to be done.
Added to this there is the fact that the problems with namespaces are entirely inherited from an existing extension that is poorly documented and, as we have just discovered, poorly understood. For all the reasons explained in the proposal we are likely to be leaning more heavily on ExplicitNameSpaces as we develop DH so we really need sort out what it does and get it written down. Here is the kicker — when we do sort out ExplicitNameSpaces and write it up properly we are going to want it attached to language extension dedicated to managing ExplicitNameSpaces, not an extension bundled up with some enabled warnings.
I am happy to work with Artyom to get the new proposal set up etc.
Chris
On 13 Dec 2022, at 09:01, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal.
I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it.
Simon
On Mon, 12 Dec 2022 at 22:05, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote: In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view.
It sounds like we are in strong agreement.
Chris
On 12 Dec 2022, at 20:11, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote:
On 12/12/2022 16:50, Chris Dornan wrote:
I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly.
This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features!
I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions?
Adam
> On 12 Dec 2022, at 12:21, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>> wrote: > > On 12/12/2022 11:39, Simon Peyton Jones wrote: >> {-# LANGUAGE ExplicitNamespaces #-} >> module N where >> import M (T(type MkT)) -- NB "type" import of a data constructor >> v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above. > > The nested use is already possible with ExplicitNamespaces. Currently it allows > > import M (T(type MkT)) > import M (type MkT) > import M (pattern MkT) > > whereas the proposal extends it to add the possibility to write > > import M type (MkT) > import M data (MkT) > import M (data MkT) > > >> In general, I don't feel the extensions to ExplicitNamespaces included >> in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification> <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>>>. It only covers >> import M *type * >> import M *data *as MD >> where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal? > > I'm trying to understand what > > import M type (MkT) > > means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing > > import M (T(type MkT)) > > which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>>). > > I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something? > > Cheers, > > Adam > > >> On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>> <mailto:adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>>> wrote: >> Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>> >> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>>> I >> realised I'm unclear how the proposed extensions to ExplicitNamespaces >> are supposed to work. The existing situation is apparently that for a >> (non-punned) data constructor, it is possible to use either a >> pattern or >> type qualifier in an import list (presumably because DataKinds means >> the >> constructor is in scope at both the term and type levels), and the >> imported constructor is then usable in both contexts. >> For example, the following is accepted at present: >> module M where >> data T = MkT >> {-# LANGUAGE ExplicitNamespaces #-} >> module N where >> import M (T(type MkT)) -- NB "type" import of a data constructor >> v = MkT -- usage at term level >> The present proposal says "With type specified in the import, only >> identifiers belonging to the type namespace will be brought into the >> scope." I'm not exactly sure how to interpret this, does it mean the >> following alternative will be accepted or rejected? >> module N where >> import M type (MkT) >> v = MkT >> I'm worried we will end up with a situation where ExplicitNamespaces >> does subtly different things depending on the position of the keyword. >> In general, I don't feel the extensions to ExplicitNamespaces included >> in the proposal are very clearly specified. Given the discussion about >> exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus >> separate extensions, perhaps we should accept the parts relating to >> -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be >> proposed separately? >> Cheers, >> Adam >> On 09/12/2022 11:11, Adam Gundry wrote: >> > I'm broadly in favour of accepting the proposal. I realise the >> history >> > is complex here, so I don't think we should ask anyone to rewrite >> things >> > further, though in general it would be nicer to have separate >> proposals >> > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the >> > changes to imports (which as Joachim points out raise issues). >> > >> > I'm a bit concerned that the proposal does not motivate or specify >> > -Wpattern-namespace-qualified very well. >> > >> > >> > On 08/12/2022 08:33, Joachim Breitner wrote: >> >> ... >> >> >> >> This gives us (at least) these options: >> >> >> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to >> GHC2023, >> >> introduce one or two new extensions for the newer changes. >> >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >> >> disregarding issue #551. >> >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >> >> arguing that GHC20xx allows more liberal (backward-compatibile) >> >> changes than, say, Haskell2010 would allow. >> >> >> >> Certainly 1 is the least bold move. I am not sure what the best way >> >> forwards is, and welcome other opinions. >> > >> > I would prefer a variant of 1: allow "data" as a keyword in >> import lists >> > under ExplicitNamespaces, but make the other changes under other >> > extensions. >> > >> > As I've said previously, I have a general preference for multiple >> small, >> > orthogonal extensions rather than changing existing extensions to >> add >> > unrelated features that happen to be in similar territory. I realise >> > this is controversial, of course. >> > >> > Cheers, >> > >> > Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ <https://www.well-typed.com/>
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
On 15/12/2022 16:49, Chris Dornan wrote:
Does anybody object to us accepting #270 now? Speak now, etc.
I object to accepting #270 as-is, I'm afraid. I'm content to accept the parts relating to -Wpuns/-Wpun-bindings, which seem to be relatively well-motivated and specified in the proposal (albeit primarily by the medium of examples). Indeed they form the bulk of the proposal content! However the parts related to extensions seem problematic and have given rise to substantial discussion: * We don't yet have a clear consensus on the approach to language extensions (as is being discussed elsewhere), which makes it difficult to reach agreement on whether the proposal should be modifying existing extensions or introducing new ones. * In particular, if we modify ExplicitNamespaces it will become more problematic to introduce it as part of GHC2023, which leaves https://github.com/ghc-proposals/ghc-proposals/issues/551 unresolved. * ExplicitNamespaces is under-specified at present, which is not the proposer's fault, but by modifying it we will make it yet more complex and inconsistent (e.g. allowing either "type" or "data" at the top level, but only "type" in the impspec unless PatternSynonyms is enabled). * I disagree with Simon's "The proposal is quite clear about the delta to ExplicitNameSpaces." For example, it doesn't specify or provide any examples of imports with an impspec; does "import M type (T(MkT))" silently import T but not MkT, or it it an error? * The change to PatternSynonyms and introducing of -Wpattern-namespace-qualifier is not clearly motivated in the text (though one can imagine some motivations), and we should consider whether breaking old code in this way is justified. I'm sure these issues can be resolved, but I think the best way to do so is to accept the -Wpuns/-Wpun-bindings parts of the proposal, while asking for the changes to extensions to be raised as a separate proposal with its own motivation, specification and examples. (This isn't about "formatting", so if splitting the proposal seems problematic it would also be fine for the whole proposal to be resubmitted; but that seems like it will be harder than a split.) I would point out the guidelines in our README:
If the technical debate is not rapidly resolved, the shepherd should return the proposal for revision. Further technical discussion can then take place, the author can incorporate that conclusions in the proposal itself, and re-submit it. Returning a proposal for revision is not a negative judgement; on the contrary it might connote "we absolutely love this proposal but we want it to be clear on these points".
In fact, this should happen if any substantive technical debate takes place. The goal of the committee review is to say yes/no to a proposal as it stands.
With apologies for causing controversy, Adam
On 15 Dec 2022, at 08:14, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
I recommend acceptance as-is.
I see no difficulty with the namespace part of the proposal. Yes, the /existing /namespace extension is ill specified. But this proposal does not make that situation worse (the delta is clearly specified), and it seems unfair of us to penalise this proposal because of the pre-existing situation.
Of course, it would be better still to have a new, subsequent proposal that clarifies the ExplicitNameSpaceProposal. Perhaps we could invite Artyom write it, as a favour to the community. Or perhaps a member of the committee might like to.
Simon
On Thu, 15 Dec 2022 at 00:55, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote:
For reasons I have made entirely clear I _strongly_ desire this split — are you offering to take over shepherding this proposal Richard? Because I am now totally stymied and unable to manage the process.
On 15 Dec 2022, at 00:47, Richard Eisenberg <lists@richarde.dev <mailto:lists@richarde.dev>> wrote:
I strongly oppose requesting that the proposal be split. I agree that the two parts of the proposal can notionally be separated. But sometimes I feel that, in the face of difficult decisions, this committee has punted by requesting formatting changes of proposals. My case in point is around #448 about scoped type variables. That proposal arose out of a smattering of other proposals... but the committee deemed that the other proposals were too separate and needed to be considered as a whole. So, with some effort, I put them all in one. Then members of the committee said that the proposal was too big and to break it up! I refused, and had to hold my ground despite several requests. In the end, half was accepted, and at that point I took the other half and re-proposed it. I actually don't mind that last part -- I think partial acceptance is a reasonable action. But the formatting and reformatting is quite a bit of work, and I'm not convinced it really helped our debate. I'm worried we're repeating this here.
Richard
On Dec 13, 2022, at 10:50 AM, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote:
Although the two aspects of the proposal were motivated by the same problem they are doing completely different things. As long as it was easier to deal with them together the path of least resistance was to keep them bundled up, but it is becoming ever clearer that they are tied up in divergent organisational as well as technical concerns. The warnings are well understood and ready to go with a patch whereas, as this thread illustrates, nobody seems to properly understand what is going on with ExplicitNameSpaces; we are still confident that we can sort it all out and confident that we want to sort it all out but still there is work to be done.
Added to this there is the fact that the problems with namespaces are entirely inherited from an existing extension that is poorly documented and, as we have just discovered, poorly understood. For all the reasons explained in the proposal we are likely to be leaning more heavily on ExplicitNameSpaces as we develop DH so we really need sort out what it does and get it written down. Here is the kicker — when we do sort out ExplicitNameSpaces and write it up properly we are going to want it attached to language extension dedicated to managing ExplicitNameSpaces, not an extension bundled up with some enabled warnings.
I am happy to work with Artyom to get the new proposal set up etc.
Chris
On 13 Dec 2022, at 09:01, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal.
I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it.
Simon
On Mon, 12 Dec 2022 at 22:05, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote:
In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view.
It sounds like we are in strong agreement.
Chris
> On 12 Dec 2022, at 20:11, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote: > > On 12/12/2022 16:50, Chris Dornan wrote: >> I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. >> I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. >> I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. >> Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly. > > This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features! > > I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions? > > Adam > > >>> On 12 Dec 2022, at 12:21, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>> wrote: >>> >>> On 12/12/2022 11:39, Simon Peyton Jones wrote: >>>> {-# LANGUAGE ExplicitNamespaces #-} >>>> module N where >>>> import M (T(type MkT)) -- NB "type" import of a data constructor >>>> v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above. >>> >>> The nested use is already possible with ExplicitNamespaces. Currently it allows >>> >>> import M (T(type MkT)) >>> import M (type MkT) >>> import M (pattern MkT) >>> >>> whereas the proposal extends it to add the possibility to write >>> >>> import M type (MkT) >>> import M data (MkT) >>> import M (data MkT) >>> >>> >>>> In general, I don't feel the extensions to ExplicitNamespaces included >>>> in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification> <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>>>. It only covers >>>> import M *type * >>>> import M *data *as MD >>>> where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal? >>> >>> I'm trying to understand what >>> >>> import M type (MkT) >>> >>> means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing >>> >>> import M (T(type MkT)) >>> >>> which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>>). >>> >>> I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something? >>> >>> Cheers, >>> >>> Adam >>> >>> >>>> On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>> <mailto:adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>>> wrote: >>>> Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>> >>>> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>>> I >>>> realised I'm unclear how the proposed extensions to ExplicitNamespaces >>>> are supposed to work. The existing situation is apparently that for a >>>> (non-punned) data constructor, it is possible to use either a >>>> pattern or >>>> type qualifier in an import list (presumably because DataKinds means >>>> the >>>> constructor is in scope at both the term and type levels), and the >>>> imported constructor is then usable in both contexts. >>>> For example, the following is accepted at present: >>>> module M where >>>> data T = MkT >>>> {-# LANGUAGE ExplicitNamespaces #-} >>>> module N where >>>> import M (T(type MkT)) -- NB "type" import of a data constructor >>>> v = MkT -- usage at term level >>>> The present proposal says "With type specified in the import, only >>>> identifiers belonging to the type namespace will be brought into the >>>> scope." I'm not exactly sure how to interpret this, does it mean the >>>> following alternative will be accepted or rejected? >>>> module N where >>>> import M type (MkT) >>>> v = MkT >>>> I'm worried we will end up with a situation where ExplicitNamespaces >>>> does subtly different things depending on the position of the keyword. >>>> In general, I don't feel the extensions to ExplicitNamespaces included >>>> in the proposal are very clearly specified. Given the discussion about >>>> exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus >>>> separate extensions, perhaps we should accept the parts relating to >>>> -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be >>>> proposed separately? >>>> Cheers, >>>> Adam >>>> On 09/12/2022 11:11, Adam Gundry wrote: >>>> > I'm broadly in favour of accepting the proposal. I realise the >>>> history >>>> > is complex here, so I don't think we should ask anyone to rewrite >>>> things >>>> > further, though in general it would be nicer to have separate >>>> proposals >>>> > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the >>>> > changes to imports (which as Joachim points out raise issues). >>>> > >>>> > I'm a bit concerned that the proposal does not motivate or specify >>>> > -Wpattern-namespace-qualified very well. >>>> > >>>> > >>>> > On 08/12/2022 08:33, Joachim Breitner wrote: >>>> >> ... >>>> >> >>>> >> This gives us (at least) these options: >>>> >> >>>> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to >>>> GHC2023, >>>> >> introduce one or two new extensions for the newer changes. >>>> >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >>>> >> disregarding issue #551. >>>> >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >>>> >> arguing that GHC20xx allows more liberal (backward-compatibile) >>>> >> changes than, say, Haskell2010 would allow. >>>> >> >>>> >> Certainly 1 is the least bold move. I am not sure what the best way >>>> >> forwards is, and welcome other opinions. >>>> > >>>> > I would prefer a variant of 1: allow "data" as a keyword in >>>> import lists >>>> > under ExplicitNamespaces, but make the other changes under other >>>> > extensions. >>>> > >>>> > As I've said previously, I have a general preference for multiple >>>> small, >>>> > orthogonal extensions rather than changing existing extensions to >>>> add >>>> > unrelated features that happen to be in similar territory. I realise >>>> > this is controversial, of course. >>>> > >>>> > Cheers, >>>> > >>>> > Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
Thanks Adam, You have nothing to apologise for — it is the rest of us that should be apologising to you! I can hardly disagree with anything you say as it, belatedly, lines with my own view. In my view this proposal has been highly productive in highlighting the issues around puns and proposing warnings, with a patch. But also productive for highlighting the state of the ExplicitNamespaces extension. The author has shown the patience of a saint and I would be citing him for a medal if it were possible. I will attempt to convey my gratitude and see if we can prevail upon him to help us with the follow-up. While it was very tempting to just accept the proposal and try and patch things up, this I feel sure this is actually the right course of action (TM). I am so glad you are on the committee! Chris
On 15 Dec 2022, at 20:06, Adam Gundry <adam@well-typed.com> wrote:
On 15/12/2022 16:49, Chris Dornan wrote:
Does anybody object to us accepting #270 now? Speak now, etc.
I object to accepting #270 as-is, I'm afraid.
I'm content to accept the parts relating to -Wpuns/-Wpun-bindings, which seem to be relatively well-motivated and specified in the proposal (albeit primarily by the medium of examples). Indeed they form the bulk of the proposal content!
However the parts related to extensions seem problematic and have given rise to substantial discussion:
* We don't yet have a clear consensus on the approach to language extensions (as is being discussed elsewhere), which makes it difficult to reach agreement on whether the proposal should be modifying existing extensions or introducing new ones.
* In particular, if we modify ExplicitNamespaces it will become more problematic to introduce it as part of GHC2023, which leaves https://github.com/ghc-proposals/ghc-proposals/issues/551 unresolved.
* ExplicitNamespaces is under-specified at present, which is not the proposer's fault, but by modifying it we will make it yet more complex and inconsistent (e.g. allowing either "type" or "data" at the top level, but only "type" in the impspec unless PatternSynonyms is enabled).
* I disagree with Simon's "The proposal is quite clear about the delta to ExplicitNameSpaces." For example, it doesn't specify or provide any examples of imports with an impspec; does "import M type (T(MkT))" silently import T but not MkT, or it it an error?
* The change to PatternSynonyms and introducing of -Wpattern-namespace-qualifier is not clearly motivated in the text (though one can imagine some motivations), and we should consider whether breaking old code in this way is justified.
I'm sure these issues can be resolved, but I think the best way to do so is to accept the -Wpuns/-Wpun-bindings parts of the proposal, while asking for the changes to extensions to be raised as a separate proposal with its own motivation, specification and examples. (This isn't about "formatting", so if splitting the proposal seems problematic it would also be fine for the whole proposal to be resubmitted; but that seems like it will be harder than a split.)
I would point out the guidelines in our README:
If the technical debate is not rapidly resolved, the shepherd should return the proposal for revision. Further technical discussion can then take place, the author can incorporate that conclusions in the proposal itself, and re-submit it. Returning a proposal for revision is not a negative judgement; on the contrary it might connote "we absolutely love this proposal but we want it to be clear on these points".
In fact, this should happen if any substantive technical debate takes place. The goal of the committee review is to say yes/no to a proposal as it stands.
With apologies for causing controversy,
Adam
On 15 Dec 2022, at 08:14, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
I recommend acceptance as-is.
I see no difficulty with the namespace part of the proposal. Yes, the /existing /namespace extension is ill specified. But this proposal does not make that situation worse (the delta is clearly specified), and it seems unfair of us to penalise this proposal because of the pre-existing situation.
Of course, it would be better still to have a new, subsequent proposal that clarifies the ExplicitNameSpaceProposal. Perhaps we could invite Artyom write it, as a favour to the community. Or perhaps a member of the committee might like to.
Simon
On Thu, 15 Dec 2022 at 00:55, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote:
For reasons I have made entirely clear I _strongly_ desire this split — are you offering to take over shepherding this proposal Richard? Because I am now totally stymied and unable to manage the process.
On 15 Dec 2022, at 00:47, Richard Eisenberg <lists@richarde.dev <mailto:lists@richarde.dev>> wrote:
I strongly oppose requesting that the proposal be split. I agree that the two parts of the proposal can notionally be separated. But sometimes I feel that, in the face of difficult decisions, this committee has punted by requesting formatting changes of proposals. My case in point is around #448 about scoped type variables. That proposal arose out of a smattering of other proposals... but the committee deemed that the other proposals were too separate and needed to be considered as a whole. So, with some effort, I put them all in one. Then members of the committee said that the proposal was too big and to break it up! I refused, and had to hold my ground despite several requests. In the end, half was accepted, and at that point I took the other half and re-proposed it. I actually don't mind that last part -- I think partial acceptance is a reasonable action. But the formatting and reformatting is quite a bit of work, and I'm not convinced it really helped our debate. I'm worried we're repeating this here.
Richard
On Dec 13, 2022, at 10:50 AM, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote:
Although the two aspects of the proposal were motivated by the same problem they are doing completely different things. As long as it was easier to deal with them together the path of least resistance was to keep them bundled up, but it is becoming ever clearer that they are tied up in divergent organisational as well as technical concerns. The warnings are well understood and ready to go with a patch whereas, as this thread illustrates, nobody seems to properly understand what is going on with ExplicitNameSpaces; we are still confident that we can sort it all out and confident that we want to sort it all out but still there is work to be done.
Added to this there is the fact that the problems with namespaces are entirely inherited from an existing extension that is poorly documented and, as we have just discovered, poorly understood. For all the reasons explained in the proposal we are likely to be leaning more heavily on ExplicitNameSpaces as we develop DH so we really need sort out what it does and get it written down. Here is the kicker — when we do sort out ExplicitNameSpaces and write it up properly we are going to want it attached to language extension dedicated to managing ExplicitNameSpaces, not an extension bundled up with some enabled warnings.
I am happy to work with Artyom to get the new proposal set up etc.
Chris
On 13 Dec 2022, at 09:01, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal.
I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it.
Simon
On Mon, 12 Dec 2022 at 22:05, Chris Dornan <chris@chrisdornan.com <mailto:chris@chrisdornan.com>> wrote:
In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view.
It sounds like we are in strong agreement.
Chris
> On 12 Dec 2022, at 20:11, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote: > > On 12/12/2022 16:50, Chris Dornan wrote: >> I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. >> I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. >> I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. >> Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly. > > This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features! > > I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions? > > Adam > > >>> On 12 Dec 2022, at 12:21, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>> wrote: >>> >>> On 12/12/2022 11:39, Simon Peyton Jones wrote: >>>> {-# LANGUAGE ExplicitNamespaces #-} >>>> module N where >>>> import M (T(type MkT)) -- NB "type" import of a data constructor >>>> v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above. >>> >>> The nested use is already possible with ExplicitNamespaces. Currently it allows >>> >>> import M (T(type MkT)) >>> import M (type MkT) >>> import M (pattern MkT) >>> >>> whereas the proposal extends it to add the possibility to write >>> >>> import M type (MkT) >>> import M data (MkT) >>> import M (data MkT) >>> >>> >>>> In general, I don't feel the extensions to ExplicitNamespaces included >>>> in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification> <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-... <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>>>. It only covers >>>> import M *type * >>>> import M *data *as MD >>>> where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal? >>> >>> I'm trying to understand what >>> >>> import M type (MkT) >>> >>> means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing >>> >>> import M (T(type MkT)) >>> >>> which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>>). >>> >>> I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something? >>> >>> Cheers, >>> >>> Adam >>> >>> >>>> On Mon, 12 Dec 2022 at 09:15, Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>> <mailto:adam@well-typed.com <mailto:adam@well-typed.com> <mailto:adam@well-typed.com <mailto:adam@well-typed.com>>>> wrote: >>>> Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>> >>>> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581> <https://gitlab.haskell.org/ghc/ghc/-/issues/22581 <https://gitlab.haskell.org/ghc/ghc/-/issues/22581>>> I >>>> realised I'm unclear how the proposed extensions to ExplicitNamespaces >>>> are supposed to work. The existing situation is apparently that for a >>>> (non-punned) data constructor, it is possible to use either a >>>> pattern or >>>> type qualifier in an import list (presumably because DataKinds means >>>> the >>>> constructor is in scope at both the term and type levels), and the >>>> imported constructor is then usable in both contexts. >>>> For example, the following is accepted at present: >>>> module M where >>>> data T = MkT >>>> {-# LANGUAGE ExplicitNamespaces #-} >>>> module N where >>>> import M (T(type MkT)) -- NB "type" import of a data constructor >>>> v = MkT -- usage at term level >>>> The present proposal says "With type specified in the import, only >>>> identifiers belonging to the type namespace will be brought into the >>>> scope." I'm not exactly sure how to interpret this, does it mean the >>>> following alternative will be accepted or rejected? >>>> module N where >>>> import M type (MkT) >>>> v = MkT >>>> I'm worried we will end up with a situation where ExplicitNamespaces >>>> does subtly different things depending on the position of the keyword. >>>> In general, I don't feel the extensions to ExplicitNamespaces included >>>> in the proposal are very clearly specified. Given the discussion about >>>> exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus >>>> separate extensions, perhaps we should accept the parts relating to >>>> -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be >>>> proposed separately? >>>> Cheers, >>>> Adam >>>> On 09/12/2022 11:11, Adam Gundry wrote: >>>> > I'm broadly in favour of accepting the proposal. I realise the >>>> history >>>> > is complex here, so I don't think we should ask anyone to rewrite >>>> things >>>> > further, though in general it would be nicer to have separate >>>> proposals >>>> > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the >>>> > changes to imports (which as Joachim points out raise issues). >>>> > >>>> > I'm a bit concerned that the proposal does not motivate or specify >>>> > -Wpattern-namespace-qualified very well. >>>> > >>>> > >>>> > On 08/12/2022 08:33, Joachim Breitner wrote: >>>> >> ... >>>> >> >>>> >> This gives us (at least) these options: >>>> >> >>>> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to >>>> GHC2023, >>>> >> introduce one or two new extensions for the newer changes. >>>> >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >>>> >> disregarding issue #551. >>>> >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >>>> >> arguing that GHC20xx allows more liberal (backward-compatibile) >>>> >> changes than, say, Haskell2010 would allow. >>>> >> >>>> >> Certainly 1 is the least bold move. I am not sure what the best way >>>> >> forwards is, and welcome other opinions. >>>> > >>>> > I would prefer a variant of 1: allow "data" as a keyword in >>>> import lists >>>> > under ExplicitNamespaces, but make the other changes under other >>>> > extensions. >>>> > >>>> > As I've said previously, I have a general preference for multiple >>>> small, >>>> > orthogonal extensions rather than changing existing extensions to >>>> add >>>> > unrelated features that happen to be in similar territory. I realise >>>> > this is controversial, of course. >>>> > >>>> > Cheers, >>>> > >>>> > Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
participants (6)
-
Adam Gundry -
Arnaud Spiwack -
Chris Dornan -
Joachim Breitner -
Richard Eisenberg -
Simon Peyton Jones