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 <ivanperezdominguez@gmail.com> 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.