Re: [Haskell-cafe] [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.