4 ms·
We will be introducing two sets of integer math operators in Pony. The current which are non-partial and can over/underflow + division by zero == 0 AND new ones
by spooneybarger 8y ago
We will be introducing two sets of integer math operators in Pony. The current which are non-partial and can over/underflow + division by zero == 0 AND new ones that will be partial functions that cause an error on under/overflow and division by zero.
- gopalv 8y ago> new ones that will be partial functions that cause an error on under/overflow and division by zero. A "strict" mode is usually always an afterthought once we have errors & people run it in strict mode and facepalm. One of the first "utilities" I wrote for PHP was something called "pecl/scream", which turned off all the "unchecked" operations across the whole VM. And in general, this works out poorly for code quality.
- rhencke 8y agoPony is not 1.0 yet. The language is still malleable.
- jeremyjh 8y agoThere is no golden path here. Checked exceptions for division would make a lot of Pony code objectively worse. Unchecked exceptions are great for PHP, Haskell, Rust or Go, but Pony is trying to do something different - to literally make it impossible to panic in an operation without describing that in the type system. The ergonomics of divide by zero in this context are absolutely debatable, not an issue to dismiss out-of-hand.
- garmaine 8y agoWell, except for kernel panics and hardware errors...
- jeremyjh 8y agoYou can write user code in Pony that will cause a kernel panic or hardware error?
- spooneybarger 8y agoYes. Hardware errors, can't really protect from that or a kernel panic. A kernel panic is a panic in non-pony code.
- garmaine 8y agoIt may be forced to error as a result of one.
- mpolsz 8y ago> You can write user code in Pony that will cause a kernel panic or hardware error? You can always (as in OS with lazy allocation) allocate enough memory to get OOM no matter how safe your language is.
- ghayes 8y agoCouldn’t you alternatively introduce total operators that just grow the memory size as necessary instead of overflowing? For me if you’re handling wrapped types, I’d always prefer the numbers to grow into extra memory instead of overflowing or raising exceptions. Erlang, for instance, does this well. Obviously, division may still not be total, though you could define an operator like `//` that is.
- spooneybarger 8y agoA wrapped types library with the corresponding performance tradeoff is something I expect will be added to Pony at some point. There's definitely value in them for a variety of use cases.