from Hacker News

A float walks into a gradual type system

by ruuda on 3/3/25, 7:14 AM with 8 comments

• by AlotOfReading on 3/4/25, 4:12 AM

  I thought this was going to be about NaNs, signed zeros or other things that are fundamentally different between floats and integer types. I don't really understand why accepting implied or overspecified zeros is deeply problematic here. You're already allowing the user to omit the 14+ zeros of precision actually represented in the underlying value and there's no confusion about what the correct answer is in either case. The minor ambiguity with type inference (let b = 1) can be resolved in favor of integers without surprising anyone.

• by sfink on 3/4/25, 8:16 AM

  Huh. If I had to pick a constraint to jettison from that list, I think I'd pick 1 == 1.0. In fact, I'd prefer an error when testing 1.0 == 1.0. It only makes sense to compare floats in very limited situations. While admittedly this is one of those situations where it could make sense, as long as floats aren't the result of calculations in this language, it's still better than discarding any of the other constraints given that it's not fundamentally a very meaningful operation. (One could argue that comparing float constants is ok, just not calculated floats, but it still doesn't seem that useful.)

  Then again... I have a little more trouble discarding floats as keys, including floats as set members.

  And anyway, you can't stop floats from being weird. 0 vs -0. NaN. +/-Infinity.

• by lifthrasiir on 3/4/25, 3:38 AM

  It seems that the author's notion of referential transparency is too strong because it is typically about evaluation semantics, not about a type system. You can easily imagine the case where such notion would immediately break down with usual subtyping.

• by childintime on 3/4/25, 8:34 AM

  > There were three places — fewer than I expected! — that previously were infallible by construction, but now need a runtime check to ensure that a number is an integer. For example, when indexing into a list

  A float actually sounds like the perfect way to index a list: anything in the range from from 0 to 1 (excluding either) would map to the first element. It works just like the wheel of fortune. Well almost, with the wheel exactly 0 or 1 would be invalid. So you might want to index using 0.5, 1.5, etc instead, and the implementation can round up or down the way it wants. We've solved a language incompatibility issue, lol </rant>