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 <marlowsd@gmail.com>:
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 <marlowsd@gmail.com> wrote:
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 <marlowsd@gmail.com> wrote:
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 <ghc-steering-committee@haskell.org> wrote:
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/proposals/0698-qualified-literals.rst
> >
> > 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#committee-process-for-responding-to-a-proposal
> > (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