3 ms·

Seems interesting though I can not say that I like the Ada inheritance (especially the interface files, but the verbosity as well, the lack of tuples and verbos

Seems interesting though I can not say that I like the Ada inheritance (especially the interface files, but the verbosity as well, the lack of tuples and verbosity of Pair seems like it would quickly be frustrating with a linear type system, as well as the seeming lack of same-scope shadowing). Shame the examples are a bit too simplistic to show the value of linearity e.g. function closeFile(file: File): Unit; that's the wrong interface, because closing a file can error. And it is an issue with destructors, which linear types can solve. It would also demonstrate runtime error handling, which is completely ignored by the entire document and largely absent from the spec (error handling is discussed a lot, but never actually demonstrated). The only document I found was https://austral-lang.org/tutorial/errors https://austral-lang.org/tutorial/errors which seems to indicate that not only does Austral (unfortunately imo) follows Haskell's lead through using an Either for errors (which is clear as mud), it proceeds to break Haskell's mnemonic for success/failure (not that that's great, but at least it was something).

trashburger 4y ago
>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
  > 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.

trashburger 4y ago

>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
> 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.