Skip to content
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

Better pretty printing of infix type operators with default fixity #670

Closed
yav opened this issue Dec 13, 2019 · 3 comments · Fixed by #671
Closed

Better pretty printing of infix type operators with default fixity #670

yav opened this issue Dec 13, 2019 · 3 comments · Fixed by #671

Comments

@yav
Copy link
Member

yav commented Dec 13, 2019

Here is an example:

type x +++ y = x-y
  
g : [6 +++ 2 +++ 1]
g = 2

If we ask for the type of g we get this:

Main> :t g
g : [(+++) ((+++) 6 2) 1]

In contrast, if we add and explicit fixity declaration, for example, infixl 5 +++ , then we get a much nicer looking type:

Main> :t g
g : [6 +++ 2 +++ 1]
@brianhuffman
Copy link
Contributor

brianhuffman commented Dec 13, 2019

A nice solution might be that if we don't declare a fixity for an infix operator, we can print it infix, but always put parentheses around it to make it unambiguous.

Similarly, we should probably require disambiguating parentheses when parsing any infix operator without a fixity. In particular, 6 +++ 2 +++ 1 should probably be a fixity error upon parsing, because the user didn't specify either left- or right-associativity.

@yav
Copy link
Member Author

yav commented Dec 13, 2019

I think the current default is that if you don't specify it explicitly it is left-associative. Are you saying we should make the default non-associative? Or just reject uses of operators unless there is an explicit fixity declaration?

I don't have a strong opinion, but I think we should probably do the same thing at the value and type.
If we require fixities to be always explicit we may have to allow local fixity declarations too (I am not sure if allow them at the moment).

@brianhuffman
Copy link
Contributor

I think defaulting to non-associative would make the most sense. (Haskell doesn't do that, but they don't have non-associative operators at all; they probably would if they did.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants