+1 This has traditionally been a pain point for Haskell newcomers, so any fix is welcome. El El mié, 15 jul 2020 a las 11:07, Richard Eisenberg escribió:

On Jul 15, 2020, at 8:58 AM, Joachim Breitner wrote:

I suggest we accept that proposal.

+1

Yes, let's accept -- and if we act quickly, it can be so for 8.12.

Thanks, Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hello, I understand the problem, but let me make sure I understand the solution, as the proposal is rather terse and refers to the other proposal, that introduces the exotic lexing scheme. So am I right in understanding that `f-1` will lex as `f - 1`, but `f -1` will lext as `f (-1)`? The reason this would work like that is because the "white space" token before the `-` is not "closing" and so we know to parse a negative literal. Just as a note, I never quite understood how we plan to implement #229---is it supposed to be done through state in the lexer, or do we have a simple lexer that keeps all tokens, including white space, and then write a post-processing function to glue and rejigger tokens? -Iavor On Wed, Jul 15, 2020 at 9:05 AM Spiwack, Arnaud wrote:

I've got no strong opinion. But it does sound reasonable to me.

Maybe this should also be a signal to deprecate NegativeLiterals in favour of LexicalNegation.

On Wed, Jul 15, 2020 at 11:16 AM Alejandro Serrano Mena wrote:

...

+1

This has traditionally been a pain point for Haskell newcomers, so any fix is welcome.

El El mié, 15 jul 2020 a las 11:07, Richard Eisenberg escribió:

...

On Jul 15, 2020, at 8:58 AM, Joachim Breitner wrote:

I suggest we accept that proposal.

+1

Yes, let's accept -- and if we act quickly, it can be so for 8.12.

Thanks, Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Jul 22, 2020, at 1:43 PM, Joachim Breitner wrote:

...

Just as a note, I never quite understood how we plan to implement #229---is it supposed to be done through state in the lexer, or do we have a simple lexer that keeps all tokens, including white space, and then write a post-processing function to glue and rejigger tokens?

No idea here.

#229 is in fact already implemented: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/1664 I don't remember the details to explain them, but I don't think it turned out hard to implement. Richard

Hi, great, so I declare consensus will accept that proposal now. Cheers, Joachim Am Mittwoch, den 22.07.2020, 08:25 -0700 schrieb Iavor Diatchki:

Huh, good to know. I just looked at how it is done, and we are literally peeking at the characters surrounding tokens and running a bit of Haskell to guess the classification of the previous/next token. Seems a bit brittle but I guess this is not something that is likely to change. I am also surprised it didn't slow down the lexer, but maybe it's lost in the noise.

Anyway, I don't have a strong opinion on the proposal as this is an extension I never use, but the proposed behavior seems more intuitive for humans, so it seems reasonable to accept it.

Iavor

On Wed, Jul 22, 2020, 06:49 Richard Eisenberg wrote:

...

...

On Jul 22, 2020, at 1:43 PM, Joachim Breitner wrote:

...

Just as a note, I never quite understood how we plan to implement #229---is it supposed to be done through state in the lexer, or do we have a simple lexer that keeps all tokens, including white space, and then write a post-processing function to glue and rejigger tokens?

No idea here.

#229 is in fact already implemented: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/1664 I don't remember the details to explain them, but I don't think it turned out hard to implement.

Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/