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/

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. 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 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 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/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

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! Let's see what others think. Committee members, speak up :-) Simon On Thu, 28 Aug 2025 at 11:58, Simon Marlow 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 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 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/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

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 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 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 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/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

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 explicitly The proposal does both of these things well, I think. BUT It 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. BUUT Desugaring 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 programs

I 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 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.

Cheers Simon

...

Let's see what others think. Committee members, speak up :-)

Simon

On Thu, 28 Aug 2025 at 11:58, Simon Marlow 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 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 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/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

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

Aug 20 was almost 3 weeks ago. I think it would be great to post a short update on the GH thread to let Brandon know that our discussion is still ongoing. Or is it? Perhaps we could accept it as is? Unclear, I'm not the shepherd. Am Fr., 29. Aug. 2025 um 10:46 Uhr schrieb Simon Peyton Jones < simon.peytonjones@gmail.com>:

I have added a comment on the GitHub proposing one way to decompose the proposals into orthogonal extensions. See fi you like it

On Fri, 29 Aug 2025 at 02:37, Arnaud Spiwack 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 explicitly

The proposal does both of these things well, I think.

BUT

It 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.

BUUT

Desugaring 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 programs

I 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 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.

Cheers Simon

...

Let's see what others think. Committee members, speak up :-)

Simon

On Thu, 28 Aug 2025 at 11:58, Simon Marlow 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 >> 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 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/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

_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.