Hacker News new | ask | show | jobs
by dllthomas 2559 days ago
> Why is it possible to "close" a file?

Because the program we're compiling needs to work on actual computers, running under actual (usually at least vaguely POSIX) operating systems. In that context, it's unavoidable that the set of open file descriptors sometimes matters. It can matter because of resource limits. It can also change whether another process gets an SIGPIPE versus blocking forever. It can affect locking.
1 comments
mlevental 2559 days ago
> Why is it possible to "close" a file?

i guess i would ask why it's possible to close a file that's going to be used after it's closed? will linear types[1] solve this?

[1] https://gitlab.haskell.org/ghc/ghc/wikis/linear-types

link
dllthomas 2559 days ago
> i guess i would ask why it's possible to close a file that's going to be used after it's closed?

I don't think there's much reason to want to do it, but it's not obvious how to enforce that while still retaining the flexibility we'd want.

Linear types expand the solution space, to be sure. Whether they "solve this" depends a bit on exactly what we consider the problem to be.

link
AnimalMuppet 2559 days ago
The file isn't going to be used after it's closed. The string from the file is going to be used after the file is closed. But with lazy IO, you don't have (all of) the string from the file yet, even though you've "read" it.

That is, the abstractions don't do what non-Haskell abstractions would lead you to expect.

link
dllthomas 2559 days ago
Right. The whole point of lazy IO is that you hide the actual IO behind values that don't appear to be IO. That means your use of the file isn't visible to the type system, so it's not really reasonable to expect it to prevent it. Unless I miss something, you can't write lazy IO without lying to the type system anyway (unsafePerformIO).
link