Fully featured support for float

[ndmitchell]

From the spec:

The Starlark floating-point data type represents an IEEE 754 double-precision floating-point number. Its type is "float".

We don't yet support floating point numbers.

[nataliejameson]

Is this supported in the java implementation in Bazel? Fine to add, but something to keep in mind as a potential compatibility issue.

[pierd]

Is anyone looking into this one? I was thinking about taking a stab at it.

@ndmitchell I'm assuming we are looking into it being a proper double precision floating-point number (aka f64 in rust). Meaning that, unlike the current integer implementation, it will have to be allocated on the heap. Is that correct?

[ndmitchell]

I don't think anyone is looking at it right now. Patch most welcome!

Yep, plan would be f64 and allocated on the heap. While int is ubiquitous in Starlark, and thus worth optimising a lot, my guess is most things in Starlark won't use float, so it's not a big deal, and we have optimised our heap a lot.

[pierd]

A quick update on how I'm going with this.

The main implementation is done. Lexer, parser, float function, / operator, float and int arithmetic operations are all functional.

Judging by float.star from starlark-go the missing bits are:

• str for floats - my current implementation uses Rust's f64::to_string which is not conformant to starlark spec
• float specific format strings (%e, %f, %g)
• using float as a dictionary key
• explicit failure when indexing strings/ranges/lists with float

I'm going to continue working on the above.

[ndmitchell]

Thanks for the info - sounds great! Note that 100% conformance with float.star is not necessary, or sometimes even a good idea - we tend to aim for https://github.com/bazelbuild/starlark/blob/master/spec.md#contents, which is mostly but not 100% equivalent.

• Formatting like Go seems fine, but the spec doesn't seem to be prescriptive, so up to you.
• https://github.com/bazelbuild/starlark/blob/master/spec.md#string-interpolation has the spec on string formatting. I'd be happy to have that as an update afterwards, or a patch initially, whatever suits you.
• For dictionaries, I imagine if you give it a hash instance it will just work.
• Do floats support to_int or not? I would guess not? Which would give you the failures for free?

[pierd]

I've removed to_int from float - you are right, it gives us the indexing failures for free. It does break %d string interpolation for floats though. It also means that float needs special handling in int() function (not too complex - added).

I've extracted get_hash implementation for ints and floats to a separate helper to make sure they always match. Now using floats as dictionary keys work as expected (together with duplicate keys detection).

With the above the missing bits are:

• string interpolations for float, that is the float specific ones (%e, %f, %g) and truncating float to int for integer ones (%d, %o, %x)
• str for float which according to the spec should work just like %g string interpolation

I think implementing these as a separate update is a good idea.

I'll clean up the code a bit and prepare a pull request so we can discuss the actual implementation.