5 ms·
How would strong typing really prevent this? This is a side effect caused by a scoping issue, calling window.print instead of the local print function.
by mpeg 7y ago
How would strong typing really prevent this? This is a side effect caused by a scoping issue, calling window.print instead of the local print function.
- lelf 7y agoYou cannot “window.print” in a Float32→Float32 function. It just won’t compile.
- H8crilA 7y agoIn what language?
- pathikrit 7y agoHaskell
- tedunangst 7y agoYou can't console.log either...
- drdaeman 7y agoThere is Debug.Trace.trace which does the trick with unsafePerformIO (which is a special non-type-safe escape hatch for IO)
- gmfawcett 7y agoYou could make it compile in Haskell. You just shouldn't: f x = unsafePerformIO $ print "boom" >> return (pi * x)
- jakear 7y agoBut of course, the function in question isn’t Math.Round. It’s “interpretDotNetFunction”. Which is, necessarily, “string -> IO ()” (forgive my syntax).
- H8crilA 7y agoHe means Haskell-grade types (float->float is not a function touching the IO monad). It wouldn't help in any mainstream language with actual types (like C++).
- mpeg 7y agoRight, that makes sense, I always thought that had more to do with the pure functional nature of Haskell than the type system, but I've never written any Haskell.
- picozeta 7y agoFrom a certain point of view that is the same thing. A pure function can only enforced using a powerful type system. Otherwise one could argue, your types are "lying". EDIT: 's/strong/powerful'
- baddox 7y agoAssuming that the function was called with a string, but the window.print function doesn't accept a string argument, the typing systems in mainstream languages like Java (or even TypeScript) would catch this bug.
- edflsafoiewq 7y agoIt's not the Math.Round function in the source text that's doing IO. IO is done as part of the function that gets run when you click "Run" run : DotNetCode -> IO () Doing IO is expected for this function (not only might the source code to be executed do IO, but the print function that was intended to be called instead of window.print certainly would).
- bradstewart 7y agoWow this suddenly made "get" the power of Haskell, which has escaped me for quite a while (not that I've ever actually written anything real with it). You can capture side effects _in the type system_. That is honestly brilliant.
- adrusi 7y agoAnswers here focus on purely functional type systems, but more generally, this type of error can be caught by effect systems https://en.m.wikipedia.org/wiki/Effect_system https://en.m.wikipedia.org/wiki/Effect_system
- alkonaut 7y ago> How would strong typing really prevent this? calling print() would not have failed in a stronger type system. However, calling print("foo") would resolve to window.print("foo") which should have failed because window.print takes zero arguments.
- Silhouette 7y agocalling print() would not have failed in a stronger type system. That depends on the type system. The notation picozeta used suggests a Haskell-style system, where you wouldn't be able to call a function that does I/O from a function that is pure, which a type like `Integer -> Float32 -> Float32` would guarantee. You would need to explicitly permit I/O with a type like `Integer -> Float32 -> IO Float32` for the Round function for the call to print to compile in this sort of system. Edit: Although it looks like the code that calls print in this case is actually another function, which might need to be in IO anyway if you were in this sort of type system, so maybe that doesn't help here.