<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">
{-# LANGUAGE ExplicitNamespaces #-}<br>
module N where<br>
import M (T(type MkT)) -- NB "type" import of a data constructor<br>
v = MkT -- usage at term level
</div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:tahoma,sans-serif" class="gmail_default">
In general, I don't feel the extensions to ExplicitNamespaces included <br>
in the proposal are very clearly specified.
</div></blockquote><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Actually isn't the proposal pretty clear on this, namely the first bullet of <a href="https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification">proposed change spec</a>. It only covers <br></div><div style="font-family:tahoma,sans-serif;margin-left:40px" class="gmail_default">import M <b>type </b><br></div><div style="font-family:tahoma,sans-serif;margin-left:40px" class="gmail_default">import M <b>data </b>as MD</div><div style="font-family:tahoma,sans-serif" class="gmail_default">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?</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif;margin-left:40px" class="gmail_default"></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 12 Dec 2022 at 09:15, Adam Gundry <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Actually, reading <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/22581" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/issues/22581</a> I <br>
realised I'm unclear how the proposed extensions to ExplicitNamespaces <br>
are supposed to work. The existing situation is apparently that for a <br>
(non-punned) data constructor, it is possible to use either a pattern or <br>
type qualifier in an import list (presumably because DataKinds means the <br>
constructor is in scope at both the term and type levels), and the <br>
imported constructor is then usable in both contexts.<br>
<br>
For example, the following is accepted at present:<br>
<br>
module M where<br>
data T = MkT<br>
<br>
{-# LANGUAGE ExplicitNamespaces #-}<br>
module N where<br>
import M (T(type MkT)) -- NB "type" import of a data constructor<br>
v = MkT -- usage at term level<br>
<br>
The present proposal says "With type specified in the import, only <br>
identifiers belonging to the type namespace will be brought into the <br>
scope." I'm not exactly sure how to interpret this, does it mean the <br>
following alternative will be accepted or rejected?<br>
<br>
module N where<br>
import M type (MkT)<br>
v = MkT<br>
<br>
I'm worried we will end up with a situation where ExplicitNamespaces <br>
does subtly different things depending on the position of the keyword.<br>
<br>
In general, I don't feel the extensions to ExplicitNamespaces included <br>
in the proposal are very clearly specified. Given the discussion about <br>
exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus <br>
separate extensions, perhaps we should accept the parts relating to <br>
-Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be <br>
proposed separately?<br>
<br>
Cheers,<br>
<br>
Adam<br>
<br>
<br>
On 09/12/2022 11:11, Adam Gundry wrote:<br>
> I'm broadly in favour of accepting the proposal. I realise the history <br>
> is complex here, so I don't think we should ask anyone to rewrite things <br>
> further, though in general it would be nicer to have separate proposals <br>
> for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the <br>
> changes to imports (which as Joachim points out raise issues).<br>
> <br>
> I'm a bit concerned that the proposal does not motivate or specify <br>
> -Wpattern-namespace-qualified very well.<br>
> <br>
> <br>
> On 08/12/2022 08:33, Joachim Breitner wrote:<br>
>> ...<br>
>><br>
>> This gives us (at least) these options:<br>
>><br>
>> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023,<br>
>> introduce one or two new extensions for the newer changes.<br>
>> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023,<br>
>> disregarding issue #551.<br>
>> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023,<br>
>> arguing that GHC20xx allows more liberal (backward-compatibile)<br>
>> changes than, say, Haskell2010 would allow.<br>
>><br>
>> Certainly 1 is the least bold move. I am not sure what the best way<br>
>> forwards is, and welcome other opinions.<br>
> <br>
> I would prefer a variant of 1: allow "data" as a keyword in import lists <br>
> under ExplicitNamespaces, but make the other changes under other <br>
> extensions.<br>
> <br>
> As I've said previously, I have a general preference for multiple small, <br>
> orthogonal extensions rather than changing existing extensions to add <br>
> unrelated features that happen to be in similar territory. I realise <br>
> this is controversial, of course.<br>
> <br>
> Cheers,<br>
> <br>
> Adam<br>
> <br>
> <br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>