upvote

points

by robertlagrant9 hours ago |
comments
upvoteby winwang8 hours ago|
next
[-]
Every day, we stray closer to Haskell. Dare I say it: good!
reply
upvoteby drdaeman9 hours ago|
prev|
next
[-]
What we need are refinement types, where there’s a base type and a predicate. F* has this:

     val (/) : int -> (divisor:int { divisor <> 0 }) -> int
reply
upvoteby yeputons9 hours ago|
prev|
next
[-]
And also cannot be INT_MIN, otherwise -1 / INT_MIN is undefined behaviour(!) in C and C++.
reply
upvoteby roadbuster8 hours ago|
prev|
next
[-]
The only way to achieve this is to either put a runtime software check on a variable whenever it's assigned/used, or to literally add hardware support in processors themselves which literally throws an interrupt when a "neverShallBeZero" variable is assigned to zero.

There's no viable way to statically prove at compile-time that these variables will never become zero at runtime, ultimately forcing a system of endless runtime checks (be it software or hardware)... which is why processors already throw exception interrupts when division by zero is attempted.

reply
upvoteby inigyou7 hours ago|
parent|
next
[-]
It's possible, just extremely difficult.
reply
upvoteby colechristensen7 hours ago|
parent|
prev|
[-]
You're kind of saying the only way to do it is in software or hardware :)

An alternative https://en.wikipedia.org/wiki/Projectively_extended_real_lin...

The projectively extended real line defines division by zero, no reason you couldn't have a floating point type that implemented it.

>There's no viable way to statically prove at compile-time that these variables will never become zero at runtime

strongly typed programming languages like Ada allow for types which have ranges such as disallowing zero -- but also any arbitrary thing like you can create a floating point "degrees" type which is [0.0, 360.0] or any other ranged type

reply
upvoteby rhdunn9 hours ago|
prev|
next
[-]
It would be more flexible for a compiler to reuse the range analysis logic used in optimizations for statically verifiable divide by zeros. That way you could extend it to other things like statically verifiable overflows.
reply
upvoteby duped8 hours ago|
prev|
[-]
For stuff like niche value optimization sure. For practical arithmetic code, nah. Like with this bug, all that changed is that garbage data in gives the user an error that they tried to process garbage data. Adding a new type doesn't make the code better, it just moves the error around. And you really don't want an infix division operator to fail to type check if the right hand side isn't a nonzero type, do you?
reply