-
Notifications
You must be signed in to change notification settings - Fork 414
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
Infix operator in compound expression crashes compiler #35
Comments
This issue can be workaround by specifying a return value in 'myand definition. Currently the implementation requires that infix functions have a return type, I need to check the code to see if this dependency can be removed or if I need to add it to the specification draft. |
That workaround has itself a problem: the infix function may be polymorphic! At least 'myand is, since it is a copy of 'and. Are you planning to allow more than one type in argument and return specs? |
`myand' is part of an expression where it will be evaluated first (expressions are reduced from left to right reduction), so it requires parens on his right expression argument, else a compilation error will occur: With parens: Without parens:
|
I fail to see what is wrong with + myand 17 13 1 ! Since myand has two arguments, 17 and 13, it will yield an integer that can be added to 1 by +. |
It is not allowed to yield any value without a proper [return:] declaration in the function specification block. In my examples, in both cases, I have used your function declaration (so without any [return:] declaration). In the "with parens" example, 'myand doesn't need to return anything as it is the root of the expression, so the compiler let it pass. In the "without parens" example, 'myand needs to return a value to be used as argument for '+ operator, in contradiction to 'myand specification block, so the compiler raises an error. |
The following code
crashes the compiler with error:
The text was updated successfully, but these errors were encountered: