Hacker News Reader

Comment by jpcooper | Hacker News Reader

There’s no guarantee that you’re not calling unsafePerformIO in Haskell, which a lot of outwardly pure libraries do. In fact, wouldn’t STM be doing this under the hood? Even the FFI in Haskell allows you to import a function without the return type being in IO as long as you pinky promise that it is pure.

The idea in the end is to provide a language for working on memory concurrently. You either choose speak it or not.

View on HN

As with Rust's 'unsafe', the fact that you can explicitly circumvent checks doesn't make those checks useless. If something goes wrong you know exactly where to look.

That may be the case for Rust. I am not sure what the implications of unsafe are for the type system.

In any case, the unsafeness of unsafePerformIO and importing an FFI function as a pure function are not reflected in the type in Haskell. These are things that can and do happen.

My point was that the ability to go outside the bounds of a language does not necessarily make the language useless.

> I am not sure what the implications of unsafe are for the type system.

There are no implications, that's the point.

> the unsafeness of unsafePerformIO and importing an FFI function as a pure function are not reflected in the type in Haskell

Yes, that is correct behaviour; if it was reflected in the type it'd be call safePerformIO.

> In any case, the unsafeness of unsafePerformIO and importing an FFI function as a pure function are not reflected in the type in Haskell.

It's reflected in safe Haskell annotations. Unfortunately nobody cares about those. Haskell has a culture problem regarding safety, just like most other languages, both high level and low level (with the exception of Java, that don't make data races UB)

Reply on news.ycombinator.com