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

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.