New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Whitespace-sensitive operator parsing (~, !, @, $, $$, -) #229
Whitespace-sensitive operator parsing (~, !, @, $, $$, -) #229
Conversation
99e3d9d
to
7c19ef2
Compare
It's always fascinating to read these proposals, to discover there are extensions I've never heard of.
Is it? What extension is that? Oh, it's a laziness annotation when you've switched on Strict-by-default Datatypes. I note that syntactically it behaves as a unary prefix, as it is for irrefutable patterns. I don't really think of
If |
Yes, both of this is possible for
With Dependent Haskell, or even VDQ alone, any type could appear in terms, including equality constraints. Imagine I defined
Note the Then one could write something like this:
Now,
Frankly, I'm not a fan of these rules. I would even consider making them whitespace-sensitive in the same way this proposal treats
|
GHC currently supports at least two whitespace-sensitive operators:
This proposal suggests to add Also, the proposal discusses whitespace. Should a comment be understood to be whitespace? Or is it ignored? (I prefer the former, but the proposal should specify.) |
I agree. White space is very significant to humans, and it wastes information bandwidth not to take advantage of it. Richard has good points about |
Heh, heh. So do we grasp the livewire of white space around
I always put space both sides of |
Ah yes, I had forgotten poor old |
Yes, I think so, – added it to the proposal.
Indeed. But there's a lot of existing whitespace-sensitive syntax to consider:
Unified rules are possible, but they might cause too much breakage. I don't want to get too ambitious with the current proposal. Let's do one thing at a time. |
For the sake of a future proposal, I think we should define the unified rules in the following terms:
A loose infix occurrence should always be considered an operator. (This frees up |
Thanks that's useful terminology. It doesn't fully explain what happens with
That's why I always write composition as "loose infix". |
@AntC2 So I think the idea is that the last three would raise a warning. I could see two approaches for GHC to reach that conclusion:
It depends on the responsibility/power of these "rules" and what can be used as a criteria for whether a "rule" triggers. I don't know if this is a rabbit hole worth pursuing in this ticket. But I think that I generally like the idea of warning on/eventually freeing up those ambiguous-looking infix operator placements. Although, it would mean that expressions like this would be discouraged/eventually even stop compiling: i :: Integer
i = 1 + 2^3 So, you can't use whitespace to indicate tighter binding for readability. But you can still use parentheses for that. |
Though I see its appeal, I'm against warnings for omitting whitespace for operators, in general. This will break gobs and gobs of code (knowing that many Haskellers consider a warning to be breakage), and it doesn't seem quite necessary. One new realization here: this proposal means that GHC would reject (more) Haskell98 programs, given that |
Done, @goldfirere. In theory, we could implement |
BTW, operator For any syntax change you make, be careful it doesn't invalidate the example in the Users Guide. That shows
|
Note that in the current proposal, we treat
|
Ah, I see now, |
I glanced over |
I support this
I wouldn't describe myself as beginner, but I've been bitten by minus parsing too
THIS. So much THIS. I always put spaces before and after infix operators and rules/warnings would surely improve the situation here. It would also make a future record access syntax
One possibility would be to add a pragma, that basically hints that this operator is intended to also be used as a tight infix |
But what operators should get that pragma? Just about every operator binds tighter than something. Separately, I personally would have a hard time supporting this proposal unless it addresses at least |
@goldfirere I feel like this proposal at least moves things in the direction of unified rules for all of them—we can just exclude programs like |
How so? There is a framework, but I see no suggestions for how this framework should apply to |
That's fair. It's not obvious, and perhaps the proposal should spell it out the a chain of restrictions even if only one step is being taken to make it clear. To quickly throw together a straw-man convergence point:
I would like to ban non-loose-infix user-level infix operator application across the board, but that is the breaking change people were expressing worry about, and more than necessary to resolve these ambiguities. |
This I love. This I have always wanted for operator A couple of your other examples aren't quite right:
Module names and pattern names must begin upper case. Specifically for modules, that's how to tell a module prefix vs "tight infix" function composition. |
Classify the brackets `(|`, `|)`, `⟦`, `⟧`, `⦇`, and `⦈` as opening/closing tokens under the extensions that enable them. See also: GHC Issue #18225 (https://gitlab.haskell.org/ghc/ghc/issues/18225) and Merge Request !3339 (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3339).
Add banana and Unicode brackets to propsal #229
Generalize #229 to include consym
See ghc-proposals/ghc-proposals#229 for the cause of breakage
See ghc-proposals/ghc-proposals#229 for the cause of breakage
See ghc-proposals/ghc-proposals#229 for the cause of breakage
See ghc-proposals/ghc-proposals#229 for the cause of breakage
We propose to simplify GHC internals and the lexical syntax of Haskell by replacing ad-hoc parsing rules with whitespace-based disambiguation:
Rendered