I do see Simon M's point; it's a point that I also tried to raise in the
past and I have thought about how concretely we could have a more
orthogonal decomposition of extensions.
However, an important question to ask is: Why would users ever want to
*change* the desugaring, other than to enable new features, such as
-XQualifiedNumbers or -XQualifiedLists?
Concretely, why not decompose -XQualifiedNumbers as
* -XQualifiedNumbers desugars `M.13` to `M.fromInteger 13` (that is, the
usual desugaring)
* the new ext -XNaturalLiterals desugars `M.13` to `M.fromNatural 13`,
`M.(-13)` to `M.fromInteger -13` and `M.(1.2)` to `M.fromRational 1.2`,
*but also* it desugars `13 ` as `fromNatural 13` for a brand new type class
method `Num.fromNatural :: Num a => Natural -> a`.
That's much more orthogonal: -XNaturalLiterals affects *all* natural number
literals, qualified or not, and -XQualifiedNumbers uses the same kind of
desugaring that is used for unqualified natural numbers.
But what is the benefit? *Surely, -XNaturalLiterals should have the exact
same semantics as `-XNoNaturalLiterals`, given the proposed default
implementation of `fromNatural`.* We would assign the exact same semantics
to all programs. We would emit the exact same set of warnings for all
programs.
Therefore, I don't see a strong argument in favour of this decomposition.
-XQualifiedStrings already has the same (but rebound) desugaring as
-XOverloadedStrings. (Good.)
For -XQualifiedLists, and a potential -XNewListDesugaring (urgh) we would
arguably find ourselves with the same question as for -XNaturalLiterals.
What is the benefit? The semantics of existing code would not change, under
reasonable assumptions. Adding `buildList` to `GHC.Exts.IsList` does not
make a lot of sense, because the main use case is constructing HLists, and
for that the type parameter of `IsList l` would have to have kind `l ::
Type -> Type`; a backwards incompatible change.
Unless users activate -XQualifiedLists, there is no benefit to
-XNewListDesugaring.
Maybe there is an argument that `GHC.Exts.[1,2,3]` should be same as
`[1,2,3]` with both -XOverloadedLists and -XQualifiedLists, similarly for
`Prelude.13` and `13` with -XQualifiedNumbers, sort of like a law. But that
benefit is marginal; the laws could be expressed in terms of default
implementations of `buildList` and `fromNatural`.
A concrete cost of the orthogonal decomposition is that we need to change
the existing type classes `Num` and `GHC.Exts.IsList`.
I'm not convinced that the benefit outweighs the cost.
Am Do., 28. Aug. 2025 um 14:29 Uhr schrieb Simon Marlow : On Thu, 28 Aug 2025 at 12:32, Simon Peyton Jones <
simon.peytonjones@gmail.com> wrote: I'm suggesting we simply don't have the latter at all, on the grounds that it's not worth the added complexity. It's just syntactic sugar after
all - you don't get any new expressivity, only nicer syntax. But the *entire thing* (OverloadedLists, OverloadedStrings etc) is "just
about syntactic sugar". It's a pity to have syntactic sugar that ends up
not doing the job! The proposal lands us in a weird place though. The existing non-qualified
overloaded literals would retain the old desugaring, so you don't get to
have type-safe naturals or heterogeneous lists unless you use the new
qualified syntax, which is non-orthogonal and non-obvious. We still have
the old syntactic sugar that doesn't "do the job", but now we also have new
syntactic sugar. Cheers
Simon Let's see what others think. Committee members, speak up :-) Simon On Thu, 28 Aug 2025 at 11:58, Simon Marlow On Thu, 28 Aug 2025 at 11:34, Simon Peyton Jones <
simon.peytonjones@gmail.com> wrote: the proposal is doing two things at the same time, namely locally-rebindable-syntax for literals (very useful) and changes to numeric
and list desugaring to increase power (also useful). Doing both of these at
the same time feels like it will be another layer of complexity for people
to run into. Yes -- but since the additional bits are useful, the only alternative
is to have -XQualifiedLiterals and
-XQualifiedLiteralsMeaningSomethingABitDifferent, perhaps mutually
exclusive, or perhaps the latter overrides the former? That also carries
complexity. I'm suggesting we simply don't have the latter at all, on the grounds
that it's not worth the added complexity. It's just syntactic sugar after
all - you don't get any new expressivity, only nicer syntax. Cheers
Simon On balance I support the proposal as-is. *Everyone: the clock is ticking: please read the proposal and
express your view. * Simon On Wed, 27 Aug 2025 at 11:10, Simon Marlow Reading through the proposal it feels rather unsatisfying. Skimming
the discussion it looks like others have raised exactly the points that
bothered me: that the proposal is doing two things at the same time, namely
locally-rebindable-syntax for literals (very useful) and changes to numeric
and list desugaring to increase power (also useful). Doing both of these at
the same time feels like it will be another layer of complexity for people
to run into. I would prefer to keep the desugaring exactly as it is (albeit limited
for some use cases) and have qualified literals manage scoping only.
Trivial to explain. Not as powerful. If people really want the whole proposal as is, then I guess I'm
mildly negative but won't put up strong opposition. Cheers
Simon On Wed, 20 Aug 2025 at 11:25, Erik de Castro Lopo via
ghc-steering-committee Hi Committee, Discussion on this proposal has died down again so I have switched
it back to "pending committee review". I have just re-read the current rendered version and suggest that
we should accept this proposal. Cheers,
Erik Erik de Castro Lopo via ghc-steering-committee wrote: > Hi All,
>
> I have been assigned as shepherd for this proposal.
>
> There is still quite a bit of discussion on the GH issue and the
> text was updated as little as a week ago.
>
> As shepherd, I am currently on the fence on this one (leaning
towards
> "accept"), for the same reason brought up by @Bodgrim in the ticket
and
> due to ever increasing complexity. I think it should remain under
> revision until the GH chatter dies down a bit.
>
> Cheers,
> Erik
>
> Adam Gundry via ghc-steering-committee wrote:
>
> > Dear Committee,
> >
> > Brandon Chinn proposes to introduce new extensions for qualified
number,
> > string and list literals:
> >
> > https://github.com/ghc-proposals/ghc-proposals/pull/698
> >
https://github.com/brandonchinn178/ghc-proposals/blob/qualified-literals/pro...
> >
> > I'd like to nominate Erik as the shepherd.
> >
> > Please guide us to a conclusion as outlined in
> >
https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst#commit...
> > (thanks Sebastian for pointing out the previously broken link)
> >
> > 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
>
>
> --
>
----------------------------------------------------------------------
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee@haskell.org
>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee --
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
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
To unsubscribe send an email to
ghc-steering-committee-leave@haskell.org _______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org