I really like the in-function documentation and unit like testing in the where clause.
> # this is true
> ((1 / 3) * 3) == 1
This worries me. I know it is true mathamatically, but experience tells me trusting floats is a recipe for disaster. A approximate equal operator is safer.
Floats are such a leaky abstraction it is in my opinion better students know this early on.
You should try it and see what it does when you force it to use floats. You may find it interesting in light of your "leaky abstraction" comment. Pyret is designed precisely to make that point clear.
The article doesn't really say what's going on under the hood but I'd guess that division of integers makes rationals...
> Pyret has numbers, because we believe an 8GB machine should not limit students to using just 32 bits.
Emphasis mine. WTF, author.
But the Java sample below saying "this is false" implies that floats are a problem that is being avoided. The only reasonable solution is rationals... right?
Yep, this is a project out of the same world as Racket which does a similar thing.
If you go into the editor/REPL (https://code.pyret.org/editor)
and enter 1/3, you'll see that it gets rendered as 0.3 repeating (with a bar, not some arbitrary rounding) or if you click on it, directly as 1/3.
Floats are really a poor representation for reals, float-intervals like Frink does are much cleaner but our FPU/SIMD sucks for these kind just think about changing the rounding very often..
> # this is true
> ((1 / 3) * 3) == 1
This worries me. I know it is true mathamatically, but experience tells me trusting floats is a recipe for disaster. A approximate equal operator is safer.
Floats are such a leaky abstraction it is in my opinion better students know this early on.