Re: [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 <[email protected]>
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 <[email protected]> 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 <[email protected]>
>> 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 <
>>> [email protected]> 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
[email protected]

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