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

Precedence for infix operators #14

Open
AnthonyJacob opened this issue Jan 4, 2017 · 4 comments
Open

Precedence for infix operators #14

AnthonyJacob opened this issue Jan 4, 2017 · 4 comments
Labels

Comments

@AnthonyJacob
Copy link

AnthonyJacob commented Jan 4, 2017

Is it possible implement Haskell syntax for infix operators?

Example :

(infixr 4 +)

(1 + 2)

In this sense (infixr 4 +) is just a shorthand macro definition that gets globally applied to all expressions.

@AnthonyJacob AnthonyJacob changed the title Infix operators. Truly infix operators. Jan 4, 2017
@AnthonyJacob AnthonyJacob changed the title Truly infix operators. True infix operators. Jan 4, 2017
@lexi-lambda
Copy link
Owner

Infix operators are planned, in some way or another. The exact details are not squared away yet. However, you will need to use { curly braces } to enter “infix mode”, since there won’t be a syntactic distinction between infix operators and prefix operators like Haskell has (based on characters in identifiers). You will be able to assign associativity and precedence, though.

@lexi-lambda lexi-lambda changed the title True infix operators. Associativity and precedence for infix operators Jan 6, 2017
@AnthonyJacob
Copy link
Author

Could you elaborate why there will be no distinction between prefix and infix?

@lexi-lambda
Copy link
Owner

I would like to avoid assigning meaning to the names of identifiers. Lisp identifiers are traditionally much more lax about which characters you can use in an identifier, so you can name an identifier do-it! if you want, or even a!b@c#d$. This also avoids needing a syntax for converting prefix operators to infix ones and vice versa, since the (<>) and `elem` syntaxes wouldn’t work so well in a Lisp.

@lexi-lambda
Copy link
Owner

Associativity is now implemented in the new implementation in e7767ad, but precedence is still unimplemented. You can now specify associativity when writing a definition by writing #:fixity left or #:fixity right. left is the default.

This means type signatures can get a bit cleaner, since -> is now properly right-associative. You can now write {Integer -> Integer -> Integer}, and it will parse the way you would expect.

@lexi-lambda lexi-lambda changed the title Associativity and precedence for infix operators Precedence for infix operators May 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants