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
Negative integer and float literals #6015
Comments
Comment author: @damiendoligez The grammar given in the doc is ambiguous and it doesn't decide between your interpretation and the parser's. But if we take x - y to mean x (-y) instead of x - y, we essentially lose the binary - operator. As far as literals are concerned, it would be possible to implement what you want, but that would break every program that contains (x-1) as an expression without a space between the - and the 1. So we're not going to change the lexer/parser. If you want to suggest improvements to the doc, they will be welcome, but you should start from the trunk version because it changed a lot since 4.00. |
Comment author: @dbuenzli Note I'm only talking about literals here. But you are right that it doesn't seem to be reasonable to change the current behaviour. Regarding fixing the doc isn't it just about removing the optional "[-]" from the literals descriptions ? |
Comment author: @gasche Removing "-" from literals would be incorrect, as this is what explains why [-1] is a valid integer list for example. In the current grammar, the ambiguity between minus-as-unary-operator and minus-as-binary-operator is handled through a yacc precedence: the binary operator has precedence over the unary one. This means that in all situations that are syntactically ambiguous (it may be that only one choice is well-typed or more generally makes sense), the binary interpretation is chosen. |
Comment author: @damiendoligez Note that the doc explicitly doesn't try to be fully formal. I'm closing this as "won't fix". |
Comment author: romildo At parser.mly in the implementation, the token "MINUS" has a lower precedence than the token "prec_unary_minus", and the expressions related to the prefix and infix "-" operator are "expr MINUS expr" and "subtractive expr %prec prec_unary_minus" where "subtractive" may be "MINUS". Clearly the prefix operator is given higher precedence than the infix operator. Thus the note written by gasche seems to be wrong and the negative literal is not needed as was claimed by him. This would be enough to reopen the ticket. The solution would be to fix the documentation to remove negative numeric literals. |
Original bug ID: 6015
Reporter: @dbuenzli
Status: closed (set by @xavierleroy on 2016-12-07T10:47:35Z)
Resolution: won't fix
Priority: normal
Severity: minor
Version: 4.00.1
Category: documentation
Monitored by: @dbuenzli
Bug description
I never understood this behaviour:
sin -3.14;;
Error: This expression has type float -> float
but an expression was expected of type int
pred -1;;
Error: This expression has type int -> int
but an expression was expected of type int
If you follow the grammar production of the docs from expr [1] to integer or float literals the above programs should be interpreted correctly. So what is wrong the lexer [4,5] or the docs ?
Either one should be fixed (and I'd prefer the lexer to be fixed).
[1] http://caml.inria.fr/pub/docs/manual-ocaml/expr.html#expr
[2] http://caml.inria.fr/pub/docs/manual-ocaml/lex.html#float-literal
[3] http://caml.inria.fr/pub/docs/manual-ocaml/lex.html#integer-literal
[4] https://github.com/ocaml/ocaml/blob/trunk/parsing/lexer.mll#L246
[5] https://github.com/ocaml/ocaml/blob/trunk/parsing/lexer.mll#L248
The text was updated successfully, but these errors were encountered: