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

Named precedence levels #180

Open
evincarofautumn opened this issue Jun 19, 2017 · 5 comments
Open

Named precedence levels #180

evincarofautumn opened this issue Jun 19, 2017 · 5 comments

Comments

@evincarofautumn
Copy link
Owner

There aren’t many operators defined in the common vocabulary yet, so we still have the chance to figure out the ergonomics of custom operators. Instead of the current 0–9 precedence levels, it might be better to use named precedence levels, under the assumption that most operators could (and should) fall into a clear family, such as:

Number Name Examples
9 ?
8 tight exponential ^*
7 tight multiplicative * / %
6 tight additive + -
5 ? ~**
4 relational < > <= >= = <>
3 loose multiplicative & &&
2 loose additive | ||
1 ? --> --->
0 ?

* not yet in the common vocab
** strict difference (xor)

Pros and cons:

  • With names, it’s easier to decide which precedence level to use for an operator

  • With names, we can easily add additional precedence levels later on between existing levels

  • With numbers, it’s easier to know which operator binds tighter

@suhr
Copy link

suhr commented Jun 19, 2017

Why don't just use an operator as a precedence level? Something like infixl ÷ (/).

@evincarofautumn
Copy link
Owner Author

That could work, and it’s been done in a few languages, at least Perl6 and Fortress. I just figured it would come out more organised to use names for the groups, provided we can come up with sensible names.

@suhr
Copy link

suhr commented Jun 19, 2017

I just figured it would come out more organised to use names for the groups, provided we can come up with sensible names.

To be honest, the concept of precedence levels by itself feels like a kludge. Even though it is a most simple and direct way to implement precedences.

@sullyj3
Copy link

sullyj3 commented Jun 27, 2017

Interesting alternative approach: https://youtu.be/EZD3Scuv02g?t=31m42s

@Heimdell
Copy link

Its may be worth to do operator precedence like in Agda: you can only declare fixity and the fact that the operator in question binds tighter that some other (and the relation is not transitive).

Using operators with no order known without putting one of subexpr in () is a suntax error.

Then you have to construct a lattice, of course.

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

No branches or pull requests

4 participants