I have added a comment on the GitHub proposing one way to decompose the proposals into orthogonal extensions. See fi you like itOn Fri, 29 Aug 2025 at 02:37, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:I'm struggling to have a strong opinion on this proposal. I think for the same reason there's a debate at all: it's a rather messy set of changes.It addresses two different things:- design shortcomings in integer desugaring and the design of OverloadedLists.- a desire to (at least sometimes) rely less on type inference and control notations more explicitlyThe proposal does both of these things well, I think.BUTIt seems problematic to have two different desugaring features which are subtly different. Why would I have the option to statically reject negative numbers with qualified literals, and not with type-class based desugaring? Why can I use X.[…] and not […] for heterogeneous lists? This is unnecessarily confusing. We could possibly deprecate OverloadedLists, but probably not number-literal desugaring which is part of Haskell 98.BUUTDesugaring of numbers (via the `Num` class no less) and OverloadedLists are already so deeply integrated in the Haskell ecosystem that changing them feels hardly possible at all.So maybe we could have new extensions to control that and possibly turn this new-and-improve behaviour to be the default in a future GHC edition. Or maybe Brandon's extension should enable the new behaviour on the default desugaring. But this more or less requires an accompanying change to Base to add `fromNatural` to the `Num` class. Which is yet another can of worm.I suppose that's the problem: this is all very can-of-wormy, isn't it? But I'm not confident that the proposal is worth introducing these inconsistencies.On Fri, 29 Aug 2025 at 07:22, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:Sebastian, would you like to put your thoughts on GitHub so the author can respond?----------We would assign the exact same semantics to all programsI don't think so. I thought the whole point of separating out negative numbers was so that they could be statically rejected. So the behaviour would not be the same.Ditto lists. I don't think there is a way of retro-fitting the new API to the existing one. It's just a change, and one that allows more expressiveness.So I just don't see a way to make the two things orthogonal.Simon_______________________________________________On Thu, 28 Aug 2025 at 22:08, Sebastian Graf <sgraf1337@gmail.com> wrote: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.CheersSimonLet's see what others think. Committee members, speak up :-)SimonOn 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.CheersSimonOn balance I support the proposal as-is.Everyone: the clock is ticking: please read the proposal and express your view.SimonOn 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.CheersSimon_______________________________________________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
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
--