3 ms·

>that's the wrong interface, because closing a file can error Realistically, it shouldn't, and there's no way you would be able to handle it properly even if i

>that's the wrong interface, because closing a file can error Realistically, it shouldn't, and there's no way you would be able to handle it properly even if it did. Flush your FDs to ensure you get write errors before closing. And EBADF means there's a bigger problem in your program (you're incorrectly sharing FDs).

still_grokking 4y ago
`closeFile` is a bad example. But here are better ones: File openFile(String path) File writeString(File file, String content) Those signatures are completely wrong! Opening or writing a file can reasonably fail in multiple ways. The language does not handle any failing effects at all.
- zetalyrae 4y ago
  I left error handling out because it's an introductory post and the code would involve too many simultaneous concerns.
  - still_grokking 4y ago
    This may be a valid approach. But than this should be communicated adequately, imho. (And better, more realistic examples, that aren't glaring wrong, would be a good idea. But I fear all examples would than melt down to pure functions. But pure functions were never an issue. In any language). I really understand why someone would try to build a better language. All the premises in the blog post are right! Only that I fear that the conclusion are frankly quite off. Looks like the usual misunderstanding of "KISS" to me, to be honest. (And I don't like to be to harsh actually. I know how much work it is to come up with anything that works at all. Languages are a very unrewarding field of work sadly).
    - zetalyrae 4y ago
      I wrote: >(Error handling etc. omitted for clarity.) I've thought about this at length. The conclusions are right.
      - masklinn 4y ago
        > I wrote: You wrote that in a later example, after several simpler examples not including error handling either, and not introducing error handling at all. In fact error handling is not covered anywhere by the introductory text. The part which really grates is that this makes all the examples in the "motivation" section for linear types work against their very section: because all the destructors are infaillible, they're perfect motivations for an affine type system and implicit destructors, all they say is that a linear type system requires more work from the user for no visible value.
        zetalyrae 4y ago
        No, on the contrary: you can recover from destructor failure by returning error values, as in Haskell or Rust. With affine types, destructors must be infallible, otherwise you get the double throw problem, as in C++ or Rust. With error handling, the signatures would just be: function closeFile(file: File): Either[File, Unit]; Where returning a `File` means closing it failed. Then you can try again, or abort. And returning `Unit` means closing succeeded. You can bikeshed the exact return type endlessly.
        masklinn 4y ago
        ... That's literally my point, and what you are not demonstrating in this introductory text, and what the examples you wrote completely undermine. > With error handling, the signatures would just be: But they're not is the point, the text spends an entire section and a good 10 pages explaining linear types (thus clearly assuming the reader does not know about them), yet all the examples undermine what they're supposed to defend. If being already sold on linear types is necessary to be motivated by this section it's not doing a very good job. And, again, no coverage or explanation of error handling anywhere in the introductory text, even though that's as important as it's divisive (even more so for a language focused on safety and correctness). As originally noted I had to go hit up section 14 of the tutorial (and I can't say I'm impressed by the coverage that document provides, as it spends more time expounding about the philosophical categorisation of errors than actually demonstrating error handling capabilities and features). > Where returning a `File` means closing it failed. That's not a very useful error report, and probably wrong as well: in most situations the file handle is invalidated by closing it, even if the closure fails. In POSIX, "EBADF" reports that the file was already broken, and "EIO" reports a flush error, which usually means that the resource has gone away e.g. it was on a transient or network device which is inaccessible. "EINTR" is the only one for which is debated[0] and may leave the fd open, but even then whether any operation other than closing (again) can succeed in that case is not clear. [0] https://www.austingroupbugs.net/view.php?id=529 https://www.austingroupbugs.net/view.php?id=529
masklinn 4y ago
> Realistically, it shouldn't, and there's no way you would be able to handle it properly even if it did. So you think it is better to continue execution completely oblivious of the issue? Or do you assume `close` will straight up terminate the program if it fails? > Flush your FDs to ensure you get write errors before closing. Nothing precludes implementing `closeFile` by flushing it, returning any error as a failure, then actually closing.

still_grokking 4y ago

`closeFile` is a bad example. But here are better ones: File openFile(String path) File writeString(File file, String content) Those signatures are completely wrong! Opening or writing a file can reasonably fail in multiple ways. The language does not handle any failing effects at all.

zetalyrae 4y ago
I left error handling out because it's an introductory post and the code would involve too many simultaneous concerns.
- still_grokking 4y ago
  This may be a valid approach. But than this should be communicated adequately, imho. (And better, more realistic examples, that aren't glaring wrong, would be a good idea. But I fear all examples would than melt down to pure functions. But pure functions were never an issue. In any language). I really understand why someone would try to build a better language. All the premises in the blog post are right! Only that I fear that the conclusion are frankly quite off. Looks like the usual misunderstanding of "KISS" to me, to be honest. (And I don't like to be to harsh actually. I know how much work it is to come up with anything that works at all. Languages are a very unrewarding field of work sadly).
  - zetalyrae 4y ago
    I wrote: >(Error handling etc. omitted for clarity.) I've thought about this at length. The conclusions are right.
    - masklinn 4y ago
      > I wrote: You wrote that in a later example, after several simpler examples not including error handling either, and not introducing error handling at all. In fact error handling is not covered anywhere by the introductory text. The part which really grates is that this makes all the examples in the "motivation" section for linear types work against their very section: because all the destructors are infaillible, they're perfect motivations for an affine type system and implicit destructors, all they say is that a linear type system requires more work from the user for no visible value.
      - zetalyrae 4y ago
        No, on the contrary: you can recover from destructor failure by returning error values, as in Haskell or Rust. With affine types, destructors must be infallible, otherwise you get the double throw problem, as in C++ or Rust. With error handling, the signatures would just be: function closeFile(file: File): Either[File, Unit]; Where returning a `File` means closing it failed. Then you can try again, or abort. And returning `Unit` means closing succeeded. You can bikeshed the exact return type endlessly.
        masklinn 4y ago
        ... That's literally my point, and what you are not demonstrating in this introductory text, and what the examples you wrote completely undermine. > With error handling, the signatures would just be: But they're not is the point, the text spends an entire section and a good 10 pages explaining linear types (thus clearly assuming the reader does not know about them), yet all the examples undermine what they're supposed to defend. If being already sold on linear types is necessary to be motivated by this section it's not doing a very good job. And, again, no coverage or explanation of error handling anywhere in the introductory text, even though that's as important as it's divisive (even more so for a language focused on safety and correctness). As originally noted I had to go hit up section 14 of the tutorial (and I can't say I'm impressed by the coverage that document provides, as it spends more time expounding about the philosophical categorisation of errors than actually demonstrating error handling capabilities and features). > Where returning a `File` means closing it failed. That's not a very useful error report, and probably wrong as well: in most situations the file handle is invalidated by closing it, even if the closure fails. In POSIX, "EBADF" reports that the file was already broken, and "EIO" reports a flush error, which usually means that the resource has gone away e.g. it was on a transient or network device which is inaccessible. "EINTR" is the only one for which is debated[0] and may leave the fd open, but even then whether any operation other than closing (again) can succeed in that case is not clear. [0] https://www.austingroupbugs.net/view.php?id=529 https://www.austingroupbugs.net/view.php?id=529

masklinn 4y ago

> Realistically, it shouldn't, and there's no way you would be able to handle it properly even if it did. So you think it is better to continue execution completely oblivious of the issue? Or do you assume `close` will straight up terminate the program if it fails? > Flush your FDs to ensure you get write errors before closing. Nothing precludes implementing `closeFile` by flushing it, returning any error as a failure, then actually closing.