[ghc-proposals] Allow reserved identifiers as fields ...

older
2nd CfP: SLE 2025 - 18th ACM...

Anthony Clayden

25 Dec 2024 25 Dec '24

3:49 a.m.

And Merry Christmas to all. I counsel against allowing reserved ids to be anything other than reserved ids. "... is fraught with peril, unduly complicates the parser, and harms readability. " says a language implementer I asked. But wanting to use field names dictated outside this language's control is a realistic requirement, for which there are several general approaches. The ghc proposal as it stands seems ad-hoc and very specific to one user organisation. Furthermore, this just ain't true:

...

... SQL schemas. anyone working with those is stuck deciding between special-casing its naming, and consistently naming *everything* weirdly, ...

SQL consistently supports things like embedded spaces, fields starting upper-case [**], embedded dots or other graphics -- by no means just names that clash with reserved ids. How does it do that? And this answer seems particularly relevant when these ids are going to feed into `HasField` constraints as a type-level String: put the id between quotes.

...

orgNotification."type"

doesn't look too ugly to my eye. And to spj's repeated point: I could envisage allowing fields in `data` decls and record syntax to be quoted. (Again you couldn't use punning nor field-name as function.) The approach is sufficiently general it could be extended to `#"Label naming"`. [**] I'm particularly keen on field names starting upper case, because they're injective/part of the structure, like data constructors. AntC (Why am I posting to the cafe, not github? I seem to be blocked from posting on any topic, either on github or gitlab -- even for pages where I'm the sole author. I'd be grateful if somebody could post the above to the PR.)

Attachments:

attachment.html (text/html — 4.9 KB)

Show replies by date

Ivan Perez

25 Dec 25 Dec

3:59 p.m.

New subject: [ghc-proposals] Allow reserved identifiers as fields ...

I don't know the history of why you might be banned if you are, so I feel comfortable being the proxy. Regardless, I've posted my own opinion on github ( https://github.com/ghc-proposals/ghc-proposals/pull/668) just now and *I urge others to do the same*. Allowing keywords as anything but keywords is a very bad idea. It should not be allowed. Ivan On Tue, 24 Dec 2024 at 19:50, Anthony Clayden wrote:

...

And Merry Christmas to all.

I counsel against allowing reserved ids to be anything other than reserved ids. "... is fraught with peril, unduly complicates the parser, and harms readability. " says a language implementer I asked.

But wanting to use field names dictated outside this language's control is a realistic requirement, for which there are several general approaches. The ghc proposal as it stands seems ad-hoc and very specific to one user organisation. Furthermore, this just ain't true:

...
... SQL schemas. anyone working with those is stuck deciding between special-casing its naming, and consistently naming *everything* weirdly, ...

SQL consistently supports things like embedded spaces, fields starting upper-case [**], embedded dots or other graphics -- by no means just names that clash with reserved ids.

How does it do that? And this answer seems particularly relevant when these ids are going to feed into `HasField` constraints as a type-level String: put the id between quotes.

...
orgNotification."type"

doesn't look too ugly to my eye. And to spj's repeated point: I could envisage allowing fields in `data` decls and record syntax to be quoted. (Again you couldn't use punning nor field-name as function.)

The approach is sufficiently general it could be extended to `#"Label naming"`.

[**] I'm particularly keen on field names starting upper case, because they're injective/part of the structure, like data constructors.

AntC

(Why am I posting to the cafe, not github? I seem to be blocked from posting on any topic, either on github or gitlab -- even for pages where I'm the sole author. I'd be grateful if somebody could post the above to the PR.) _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Jons Mostovojs

26 Dec 26 Dec

2:24 p.m.

New subject: [ghc-proposals] Allow reserved identifiers as fields ...

Dear Ivan, I normally don't post, but I got quite scared after reading your commentary of the proposal. However, upon closer inspection, it became evident that it doesn't allow overriding keywords as your post suggested. (While the changes to *fbind* allow more record constructions to parse, a construction such as ``C { type = e }}`` or ``C { foo.bar = e }`` will continue to be rejected during name resolution.) Finally – ad absurdum – ["let", "it", "be"] is a valid Haskell term, despite starting with a string which is a string literal coinciding with a keyword. — Kindest regards, ¬Σ On Wed, 25 Dec 2024 at 16:01, Ivan Perez wrote:

...

I don't know the history of why you might be banned if you are, so I feel comfortable being the proxy.

Regardless, I've posted my own opinion on github ( https://github.com/ghc-proposals/ghc-proposals/pull/668) just now and *I urge others to do the same*.

Allowing keywords as anything but keywords is a very bad idea. It should not be allowed.

Ivan

On Tue, 24 Dec 2024 at 19:50, Anthony Clayden wrote:

...
And Merry Christmas to all.

I counsel against allowing reserved ids to be anything other than reserved ids. "... is fraught with peril, unduly complicates the parser, and harms readability. " says a language implementer I asked.

But wanting to use field names dictated outside this language's control is a realistic requirement, for which there are several general approaches. The ghc proposal as it stands seems ad-hoc and very specific to one user organisation. Furthermore, this just ain't true:

...
... SQL schemas. anyone working with those is stuck deciding between special-casing its naming, and consistently naming *everything* weirdly, ...

SQL consistently supports things like embedded spaces, fields starting upper-case [**], embedded dots or other graphics -- by no means just names that clash with reserved ids.

How does it do that? And this answer seems particularly relevant when these ids are going to feed into `HasField` constraints as a type-level String: put the id between quotes.

...
orgNotification."type"

doesn't look too ugly to my eye. And to spj's repeated point: I could envisage allowing fields in `data` decls and record syntax to be quoted. (Again you couldn't use punning nor field-name as function.)

The approach is sufficiently general it could be extended to `#"Label naming"`.

[**] I'm particularly keen on field names starting upper case, because they're injective/part of the structure, like data constructors.

AntC

(Why am I posting to the cafe, not github? I seem to be blocked from posting on any topic, either on github or gitlab -- even for pages where I'm the sole author. I'd be grateful if somebody could post the above to the PR.) _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Artem Pelenitsyn

2:39 p.m.

New subject: [ghc-proposals] Allow reserved identifiers as fields ...

...

...
orgNotification."type"

doesn't look too ugly to my eye.

That's what nix has when you need fields that don't lex as identifiers. So, at least some people (including me) would be familiar with that. However, it does require a certain leap in the mental model at first. -- Best, Artem On Thu, Dec 26, 2024 at 9:24 AM Jons Mostovojs wrote:

...

Dear Ivan,

I normally don't post, but I got quite scared after reading your commentary of the proposal.

However, upon closer inspection, it became evident that it doesn't allow overriding keywords as your post suggested.

(While the changes to *fbind* allow more record constructions to parse, a construction such as ``C { type = e }}`` or ``C { foo.bar = e }`` will continue to be rejected during name resolution.)

Finally – ad absurdum – ["let", "it", "be"] is a valid Haskell term, despite starting with a string which is a string literal coinciding with a keyword.

— Kindest regards, ¬Σ

On Wed, 25 Dec 2024 at 16:01, Ivan Perez wrote:

...
I don't know the history of why you might be banned if you are, so I feel comfortable being the proxy.

Regardless, I've posted my own opinion on github ( https://github.com/ghc-proposals/ghc-proposals/pull/668) just now and *I urge others to do the same*.

Allowing keywords as anything but keywords is a very bad idea. It should not be allowed.

Ivan

On Tue, 24 Dec 2024 at 19:50, Anthony Clayden < anthony.d.clayden@gmail.com> wrote:

...
And Merry Christmas to all.

I counsel against allowing reserved ids to be anything other than reserved ids. "... is fraught with peril, unduly complicates the parser, and harms readability. " says a language implementer I asked.

But wanting to use field names dictated outside this language's control is a realistic requirement, for which there are several general approaches. The ghc proposal as it stands seems ad-hoc and very specific to one user organisation. Furthermore, this just ain't true:

...
... SQL schemas. anyone working with those is stuck deciding between special-casing its naming, and consistently naming *everything* weirdly, ...

SQL consistently supports things like embedded spaces, fields starting upper-case [**], embedded dots or other graphics -- by no means just names that clash with reserved ids.

How does it do that? And this answer seems particularly relevant when these ids are going to feed into `HasField` constraints as a type-level String: put the id between quotes.

...
orgNotification."type"

doesn't look too ugly to my eye. And to spj's repeated point: I could envisage allowing fields in `data` decls and record syntax to be quoted. (Again you couldn't use punning nor field-name as function.)

The approach is sufficiently general it could be extended to `#"Label naming"`.

[**] I'm particularly keen on field names starting upper case, because they're injective/part of the structure, like data constructors.

AntC

(Why am I posting to the cafe, not github? I seem to be blocked from posting on any topic, either on github or gitlab -- even for pages where I'm the sole author. I'd be grateful if somebody could post the above to the PR.) _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Brandon Allbery

2:48 p.m.

New subject: [ghc-proposals] Allow reserved identifiers as fields ...

The quote syntax has me vaguely wondering if there would be some interaction with OverloadedLabels, but I haven't looked closely enough to see if it would be an actual problem. On Thu, Dec 26, 2024 at 9:40 AM Artem Pelenitsyn wrote:

...

...
...
orgNotification."type"

doesn't look too ugly to my eye.

That's what nix has when you need fields that don't lex as identifiers. So, at least some people (including me) would be familiar with that. However, it does require a certain leap in the mental model at first.

-- Best, Artem

On Thu, Dec 26, 2024 at 9:24 AM Jons Mostovojs wrote:

...
Dear Ivan,

I normally don't post, but I got quite scared after reading your commentary of the proposal.

However, upon closer inspection, it became evident that it doesn't allow overriding keywords as your post suggested.

(While the changes to *fbind* allow more record constructions to parse, a construction such as ``C { type = e }}`` or ``C { foo.bar = e }`` will continue to be rejected during name resolution.)

Finally – ad absurdum – ["let", "it", "be"] is a valid Haskell term, despite starting with a string which is a string literal coinciding with a keyword.

— Kindest regards, ¬Σ

On Wed, 25 Dec 2024 at 16:01, Ivan Perez wrote:

...
I don't know the history of why you might be banned if you are, so I feel comfortable being the proxy.

Regardless, I've posted my own opinion on github ( https://github.com/ghc-proposals/ghc-proposals/pull/668) just now and *I urge others to do the same*.

Allowing keywords as anything but keywords is a very bad idea. It should not be allowed.

Ivan

On Tue, 24 Dec 2024 at 19:50, Anthony Clayden < anthony.d.clayden@gmail.com> wrote:

...
And Merry Christmas to all.

I counsel against allowing reserved ids to be anything other than reserved ids. "... is fraught with peril, unduly complicates the parser, and harms readability. " says a language implementer I asked.

But wanting to use field names dictated outside this language's control is a realistic requirement, for which there are several general approaches. The ghc proposal as it stands seems ad-hoc and very specific to one user organisation. Furthermore, this just ain't true:

...
... SQL schemas. anyone working with those is stuck deciding between special-casing its naming, and consistently naming *everything* weirdly, ...

SQL consistently supports things like embedded spaces, fields starting upper-case [**], embedded dots or other graphics -- by no means just names that clash with reserved ids.

How does it do that? And this answer seems particularly relevant when these ids are going to feed into `HasField` constraints as a type-level String: put the id between quotes.

...
orgNotification."type"

doesn't look too ugly to my eye. And to spj's repeated point: I could envisage allowing fields in `data` decls and record syntax to be quoted. (Again you couldn't use punning nor field-name as function.)

The approach is sufficiently general it could be extended to `#"Label naming"`.

[**] I'm particularly keen on field names starting upper case, because they're injective/part of the structure, like data constructors.

AntC

(Why am I posting to the cafe, not github? I seem to be blocked from posting on any topic, either on github or gitlab -- even for pages where I'm the sole author. I'd be grateful if somebody could post the above to the PR.) _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh allbery.b@gmail.com

Ivan Perez

10:15 p.m.

New subject: [ghc-proposals] Allow reserved identifiers as fields ...

...

On Thu, Dec 26, 2024 at 9:24 AM Jons Mostovojs wrote:

...
...
Dear Ivan,

I normally don't post, but I got quite scared after reading your commentary of the proposal.

However, upon closer inspection, it became evident that it doesn't allow overriding keywords as your post suggested.

(While the changes to *fbind* allow more record constructions to parse, a construction such as ``C { type = e }}`` or ``C { foo.bar = e }`` will continue to be rejected during name resolution.)

It's literally from the motivating example (bold mine): @parsonsmatt commented on Jul 22

...

"This should enable the use of HasField "type" s a instances to be used with OverloadedRecordDot -* foo.type.*"

https://github.com/ghc-proposals/ghc-proposals/pull/668#issue-2423570608 https://gitlab.haskell.org/ghc/ghc/-/issues/24174 Both of those seem to indicate that a construction like *foo.type* would be allowed with that extension on. Not *foo."type"*, but *foo.type*. Also, I think we should strongly reconsider the choices being made in language design if anyone is seriously considering that, to avoid having to write foo.type_ the way to go is to design an extension that would have people write foo."type" Ivan

Anthony Clayden

10:37 p.m.

New subject: [ghc-proposals] Allow reserved identifiers as fields ...

On Fri, 27 Dec 2024 at 03:48, Brandon Allbery wrote:

...

The quote syntax has me vaguely wondering if there would be some interaction with OverloadedLabels, ...

Yes, OverloadedLabels is the thin end of the wedge. `#type` is already supported without quotes, and that's used as justification for `.type`. (But Labels starting upper case or with embedded spaces, etc aren't supported.) It's also something of a lexing/parsing disaster. ...

...

Indeed. Specifically all the developer tools are (I suspect) going to continue to treat `type` as a keyword (unless quoted). How does `blah.type` show in Visual Studio? This proposal doesn't for example include modifying HLS for the new context-awareness around reserved ids.

Ivan Perez

11 p.m.

New subject: [ghc-proposals] Allow reserved identifiers as fields ...

Just because it's possible to disambiguate with enough context, doesn't mean it's a good idea to add it. I've heard the idea of using keywords as identifiers in Haskell being proposed decades ago. It was a bad idea then, and it's a bad idea today. This extension would make Haskell harder to read. To save one character, we now have to have more context when reading Haskell. It's harder for newcomers. It's harder for experienced users. It's harder for syntax highlighters. What good reason could possibly exist to even entertain this thought? Please, make Haskell code easier to read. Ivan On Thu, 26 Dec 2024 at 14:37, Anthony Clayden wrote:

...

On Fri, 27 Dec 2024 at 03:48, Brandon Allbery wrote:

...
The quote syntax has me vaguely wondering if there would be some interaction with OverloadedLabels, ...

Yes, OverloadedLabels is the thin end of the wedge. `#type` is already supported without quotes, and that's used as justification for `.type`. (But Labels starting upper case or with embedded spaces, etc aren't supported.)

It's also something of a lexing/parsing disaster. ...

...
Indeed. Specifically all the developer tools are (I suspect) going to continue to treat `type` as a keyword (unless quoted). How does `blah.type` show in Visual Studio?

This proposal doesn't for example include modifying HLS for the new context-awareness around reserved ids.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

188

Age (days ago)

189

Last active (days ago)

List overview

Download

7 comments

5 participants

participants (5)

Anthony Clayden
Artem Pelenitsyn
Brandon Allbery
Ivan Perez
Jons Mostovojs

[ghc-proposals] Allow reserved identifiers as fields ...

tags

participants (5)