#344: Negative Literals Improved, rec: accept
Dear Committee, a refinement to the NegativeLiterals extension has been proposed by Vladislav Zavialov (int-index). https://github.com/ghc-proposals/ghc-proposals/pull/344 https://github.com/int-index/ghc-proposals/blob/negative-literals-improved/p... He noticed that x-1 parses as x (-1) which is probably not what people expect. With this change it would be parsed as x - 1 by requiring that a negative literal may not be preceded by a “closing toking”. Nice side effect: This makes NegativeLiterals a subset of LexicalNegation (according to the author). The proposal has been received positively by the crowd on Github. I suggest we accept that proposal. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
+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 <rae@richarde.dev> escribió:
On Jul 15, 2020, at 8:58 AM, Joachim Breitner <mail@joachim-breitner.de> 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
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 <trupill@gmail.com> 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 <rae@richarde.dev> escribió:
On Jul 15, 2020, at 8:58 AM, Joachim Breitner <mail@joachim-breitner.de> 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
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 <arnaud.spiwack@tweag.io> 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 <trupill@gmail.com> 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 <rae@richarde.dev> escribió:
On Jul 15, 2020, at 8:58 AM, Joachim Breitner <mail@joachim-breitner.de> 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
Hi, I guess someone needs to respond here :-) Am Mittwoch, den 15.07.2020, 09:37 -0700 schrieb Iavor Diatchki:
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.
That is my understanding. Does that affect your verdict here?
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. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
On Jul 22, 2020, at 1:43 PM, Joachim Breitner <mail@joachim-breitner.de> 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
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 <rae@richarde.dev> wrote:
On Jul 22, 2020, at 1:43 PM, Joachim Breitner <mail@joachim-breitner.de> 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
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 <rae@richarde.dev> wrote:
On Jul 22, 2020, at 1:43 PM, Joachim Breitner <mail@joachim-breitner.de> 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/
participants (5)
-
Alejandro Serrano Mena -
Iavor Diatchki -
Joachim Breitner -
Richard Eisenberg -
Spiwack, Arnaud