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

[Artem Pelenitsyn]

>>  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 <jm at memorici.de> 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 <ivanperezdominguez at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20241226/bfd81d3d/attachment.html>