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

Negative integer and float literals #6015

Closed
vicuna opened this issue May 16, 2013 · 5 comments
Closed

Negative integer and float literals #6015

vicuna opened this issue May 16, 2013 · 5 comments

Comments

@vicuna
Copy link

vicuna commented May 16, 2013

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

@vicuna
Copy link
Author

vicuna commented May 17, 2013

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.

@vicuna
Copy link
Author

vicuna commented May 17, 2013

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 ?

@vicuna
Copy link
Author

vicuna commented May 17, 2013

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.

@vicuna
Copy link
Author

vicuna commented Jul 12, 2013

Comment author: @damiendoligez

Note that the doc explicitly doesn't try to be fully formal. I'm closing this as "won't fix".

@vicuna
Copy link
Author

vicuna commented Apr 19, 2015

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.

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

No branches or pull requests

1 participant