Sort out parsing of negative number literals about dora HOT 6 CLOSED

I did some misguided attempt during lexing, but that of course doesn't work, because then stuff like i-1 doesn't get parsed correctly anymore.

Do you agree that parse_binary is a more appropriate place?

from dora.

Probably parse_unary and parse_primary. Not sure this should be done though, I don't think -a.foo() should have to be written as -(a.foo()). So this would need some kind of special handling for numbers. Is there another programming language that has this behavior?

from dora.

I don't think -a.foo() should have to be written as -(a.foo())

I agree on that, the ticket is really only focused on dealing with number literals.

For the reasons mentioned above this is slightly more complicated as we have to keep lexing it as two separate tokens, and adjust the parse afterward.

So this would need some kind of special handling for numbers. Is there another programming language that has this behavior?

I assumed that all languages (that support function calls on "primitives", e. g. not-Java) would do this – at least to me, Dora's behavior came as a big surprise.

I could check a few languages and compile a list, but overall I think it's a desirable improvement that would allow people to read numbers as they are accustomed to, not how they are tokenized underneath:

I believe people read -1 as "minus one", not as "a positive one with a unary minus applied to it".

from dora.

I certainly agree that this can be surprising, Rust seems to behave like Dora currently: -1.abs() returns -1, (-1).abs() 1. While Ruby has the behavior you propose.

There are probably good reasons for both approaches, before doing the implementation it might be a good idea to figure out the tradeoffs and whether there are potentially side-effects. For example I could certainly imagine people writing -2.sqrt() or something similar where they want - to be an unary operator that is applied on the result of sqrt.

from dora.

Not that I'm proposing this, but I was just thinking about it would be possible to only allow - as part of a literal, not as a unary operator.

A nice benefit of this would be that it would be done with a function that could return a more "correct" result type, such that

• flipSign() would return Option[Int] instead of Int, and
• abs() would return Option[Int] instead of [Int]

to allow dealing with the Int.MinValue case:

let x = Int.MinValue.flipSign() // returns None

It could also be possible to do the same thing with - as an unary operator, but I think this would be very surprising in my opinion:

let x = -Int.MinValue // returns None

I'm not proposing this, but I think this approach would put us on a path to being able to eliminate unary operators altogether:

if (someList.contains(foo).not()) ...

The above example came up because Rust users are currently debating a way to solve (perceived) issues of boolean ! operator.

from dora.

I checked the behavior in a random sample of languages, here is what I found:

                  | -1.abs() | let x = 1; -x.abs()
------------------+----------+---------------------
 C#               | -1       | -1
 D                | -1       | -1
 Dart             | -1       | -1
 Fantom           | -1       | -1
 Groovy           | -1       | -1
 Kitten           |  1       | n.a.
 JavaScript       | -1       | -1
 Nim              | -1       | -1
 Raku             | -1       | -1
 Ruby             |  1       | -1
 Rust             | -1       | -1
 Scala            |  1       | -1
 Smalltalk        |  1       | n.a.

from dora.