<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">(Simon, I'm guessing this message
should have gone to the committee list, so I'm including the full
text below.)</div>
<div class="moz-cite-prefix"><br>
</div>
<br>
<div class="moz-cite-prefix">On 12/12/2022 13:04, Simon Peyton Jones
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJKmMz-AxE+oaFRnV7fQVpxqmWXzReUy2oVTuOKHVLw08HQ9Uw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><br>
<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">
The nested use is already possible with ExplicitNamespaces.
Currently it <br>
</div>
</blockquote>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">Wow.
I had no idea. The <a
href="https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/explicit_namespaces.html?highlight=explicitnamespace#explicit-namespaces-in-import-export"
moz-do-not-send="true">user manual is entirely silent on
this point</a>. Is there some proposal that specifies this
behaviour, which the user manual is failing to document? Or
is the implementation doing something that is nowhere
specified?</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><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 class="gmail_default"
style="font-family:tahoma,sans-serif">
I'm trying to understand what `import M type (MkT)` does<br>
</div>
</blockquote>
<div><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">Well
the proposal says <br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">
<li style="margin-left:40px">With <code>type</code> specified
in the import, only identifiers belonging to the type
namespace will be brought into the scope.</li>
I took this saying "behave exactly as now, but post-filter the
imports to take only the ones from the type namespace". Today
`import M( MkT )` will be rejected; so I assume it'll still be
rejected.</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default"><br>
</div>
<div style="font-family:tahoma,sans-serif" class="gmail_default">I
agree that this point could be more clearly articulated. <br>
</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>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 12 Dec 2022 at 12:22,
Adam Gundry <<a href="mailto:adam@well-typed.com"
moz-do-not-send="true" class="moz-txt-link-freetext">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">On
12/12/2022 11:39, Simon Peyton Jones wrote:<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>
> <br>
> Crumbs. I had not realised the proposal is to allow
*nested* uses of <br>
> 'type' in import lists, as you show above.<br>
<br>
The nested use is already possible with ExplicitNamespaces.
Currently it <br>
allows<br>
<br>
import M (T(type MkT))<br>
import M (type MkT)<br>
import M (pattern MkT)<br>
<br>
whereas the proposal extends it to add the possibility to
write<br>
<br>
import M type (MkT)<br>
import M data (MkT)<br>
import M (data MkT)<br>
<br>
<br>
> In general, I don't feel the extensions to
ExplicitNamespaces included<br>
> in the proposal are very clearly specified. <br>
> <br>
> <br>
> Actually isn't the proposal pretty clear on this, namely
the first <br>
> bullet of proposed change spec <br>
> <<a
href="https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification</a>>.
It only covers<br>
> import M *type *<br>
> import M *data *as MD<br>
> where I have emboldened the new bits. Nothing about the
contents of <br>
> import lists. Why did you think your example is covered
by the proposal?<br>
<br>
I'm trying to understand what<br>
<br>
import M type (MkT)<br>
<br>
means where MkT is a data constructor (or if it raises some
kind of <br>
error). This was by analogy to the existing<br>
<br>
import M (T(type MkT))<br>
<br>
which means something today, albeit not necessarily a very
sensible <br>
thing (per <a
href="https://gitlab.haskell.org/ghc/ghc/-/issues/22581"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://gitlab.haskell.org/ghc/ghc/-/issues/22581</a>).<br>
<br>
I don't see a clear specification of the proposed (extended)
semantics <br>
of ExplicitNamespaces in the proposal, but perhaps I've missed
something?<br>
<br>
Cheers,<br>
<br>
Adam<br>
<br>
<br>
> On Mon, 12 Dec 2022 at 09:15, Adam Gundry <<a
href="mailto:adam@well-typed.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">adam@well-typed.com</a>
<br>
> <mailto:<a href="mailto:adam@well-typed.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">adam@well-typed.com</a>>>
wrote:<br>
> <br>
> Actually, reading <a
href="https://gitlab.haskell.org/ghc/ghc/-/issues/22581"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://gitlab.haskell.org/ghc/ghc/-/issues/22581</a><br>
> <<a
href="https://gitlab.haskell.org/ghc/ghc/-/issues/22581"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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<br>
> pattern or<br>
> type qualifier in an import list (presumably because
DataKinds means<br>
> 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<br>
> history<br>
> > is complex here, so I don't think we should ask
anyone to rewrite<br>
> things<br>
> > further, though in general it would be nicer to
have separate<br>
> 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<br>
> 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<br>
> 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<br>
> small,<br>
> > orthogonal extensions rather than changing
existing extensions to<br>
> 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>
</blockquote>
</div>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Adam Gundry, Haskell Consultant
Well-Typed LLP, <a class="moz-txt-link-freetext" href="https://www.well-typed.com/">https://www.well-typed.com/</a>
Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England</pre>
</body>
</html>