undefined | Better HN

0 pointsqsort5y ago0 comments

Math.tan will never throw exceptions because, for the exact same reason as above, it won't check its input.

But again for the sake of argument, the return type of tan() could be "Either<Error, double>".

0 comments

3 comments · 1 top-level

mikewarot5y ago· 2 in thread

I guess I would get used to that, but it seems broken to me. The way to deal with that is out of band, checking for the type to change to "Error"

In Pascal tan(pi/2) or tan(3pi/2) causes an overflow. The way to deal with that is out of band, to handle an exception of type E_Overflow.

qsortOP5y ago

Again no, it isn't. You are well entitled to believe Pascal is the best thing since sliced bread, but the two ideas are fundamentally different.

There is no type change. The function "tan" would return a value of type "Either<Error, double>". An expression such as:

   double x = Math.tan(Math.PI / 8)

would fail the compile-time type check, because the type of the variable "x" is "double" and the type of the expression "Math.tan(Math.PI / 8)" is "Either<Error, double>".

It would be the responsibility of the caller to prove to the type system that the error has been handled, with either a built-in language facility a la ML, or with ad-hoc code such as a Bohm-Berarducci construction.

Let's just agree to disagree.

mikewarot5y ago

I know Pascal isn't perfect, and lots has been learned since then... this is genuine confusion on my part. So tan in your system returns a variant type (could be Error, could be Double), right? (I didn't get that)

Compilers can find all sorts of things they couldn't in the past, which is amazing.

What happens at run-time if an overflow happens?

again... I'm sorry if I didn't express myself clearly enough. I'm coming at this from a Pascal programmers perspective... I've missed the past 20 years of compiler improvements.

3 more replies

j / k navigate · click thread line to collapse