3 ms·

The two most commonly referenced uses are safe mutation and better resource management. Safe mutation because when I have the only reference to a thing, the re

The two most commonly referenced uses are safe mutation and better resource management. Safe mutation because when I have the only reference to a thing, the rest of the system shouldn't care whether I change it in place or make a new one. Better resource management because you can be sure opened files are closed exactly once and that nothing tries to use a file after close, even where a bracket pattern doesn't fit (or fits much more loosely). In both cases, you're not doing anything you couldn't do before, but it lets you do it safely. People speak of performance because (especially in Haskell) mutating without being confident nothing else can see is sufficiently full of footguns that the community happily (... and rightly, IMO) pays small performance penalties for security against them. This lets us remove those performance penalties in more cases. There's some room for the compiler to notice that something is only referenced in one place and safely convert some things to mutation; again this doesn't strictly need linear types, but linear types may let us do that reasoning locally instead of it requiring whole program analysis.

klodolph 6y ago
I’ll also add that you can achieve some of these effects without linear types, but linear types are more flexible. For example, a classic way to work with a file in Haskell is to use the function withFile: withFile :: FilePath -> IOMode -> (Handle -> IO r) -> IO r You pass a function to withFile, and the file handle is valid for the scope of the function. However, this means you can’t do the following: open file A do stuff open file B do stuff close file A do stuff close file B Because the usage of files "A" and "B" don’t nest, you can’t achieve it with withFile. But you can get the same level of safety using linear types.
- tome 6y ago
  withFile also has the drawback that you can invalidly return the Handle from the handler.
  - klodolph 6y ago
    That’s true, but not much of a drawback because it’s not a likely error for humans to make and there aren’t really negative consequences.
    - dllthomas 6y ago
      Negative consequences are whatever use-after-close errors you make trying to use the thing you returned. ... but I certainly agree that it's not an error that's made very often, and the flexibility is the bigger point.
- dllthomas 6y ago
  Yeah, this is what I meant by "the bracket pattern" and a canonical case where it "doesn't fit" - I appreciate your spelling it out for those who are less familiar :)

klodolph 6y ago

I’ll also add that you can achieve some of these effects without linear types, but linear types are more flexible. For example, a classic way to work with a file in Haskell is to use the function withFile: withFile :: FilePath -> IOMode -> (Handle -> IO r) -> IO r You pass a function to withFile, and the file handle is valid for the scope of the function. However, this means you can’t do the following: open file A do stuff open file B do stuff close file A do stuff close file B Because the usage of files "A" and "B" don’t nest, you can’t achieve it with withFile. But you can get the same level of safety using linear types.

tome 6y ago
withFile also has the drawback that you can invalidly return the Handle from the handler.
- klodolph 6y ago
  That’s true, but not much of a drawback because it’s not a likely error for humans to make and there aren’t really negative consequences.
  - dllthomas 6y ago
    Negative consequences are whatever use-after-close errors you make trying to use the thing you returned. ... but I certainly agree that it's not an error that's made very often, and the flexibility is the bigger point.
dllthomas 6y ago
Yeah, this is what I meant by "the bracket pattern" and a canonical case where it "doesn't fit" - I appreciate your spelling it out for those who are less familiar :)