2 ms·

Their motivating example is dealing with a function that needs to both indicate success/failure and return a value on success. One option is to make this a fir

Their motivating example is dealing with a function that needs to both indicate success/failure and return a value on success. One option is to make this a first-class feature of the language, rather than sugar for something else. Icon (from 1977) is interesting here. https://en.wikipedia.org/wiki/Icon_%28programming_language%29 https://en.wikipedia.org/wiki/Icon_%28programming_language%2...

layer8 3y ago
Especially for failure (as opposed to just optionality), I think that exceptions are the right approach, because in general you want to transport data and type about the failure. That doesn’t imply the traditional try-catch-finally syntax — I think we can find better syntax for typical cases — but having a distinction between a normal return (type) and abnormal returns (return types). This is like a special kind of sum type where one of the options is specially distinguished.
- JonChesterfield 3y ago
  Exceptions are the wrong thing. Throw an exception means "throw away the context of the failure and then goto some other function". The exchange amounts to: Something went wrong somewhere! Where? What? I knew a moment ago but threw it away for implementation convenience. Here's an object. Thanks! Fringe benefits include sacrificing linear types - the zero runtime cost, infallible way of doing deterministic resource cleanup - and embracing the mental dissonance of goto evil unless it doesn't say where it's going to. Sum types are probably the right thing.
  - layer8 3y ago
    With checked exceptions, there is no difference from sum types in terms of interface contract and type checking. You’re not throwing anything away. The exception carries a stacktrace that tells you exactly where the failure was detected. The exception type and the data that the exception carries can give you all the data you might want about the failure. Exceptions can be chained (wrapped) to give additional context and/or to conform to an up-call-path interface contract, without losing any of the original information. Secondary failures during stack unwinding can be attached to the original exception (as for example Java does automatically in try-with-resources for resource cleanup), so in general you get a tree of errors that corresponds to the failures encountered in the call tree. This gives you much more information than the typical result codes/enums. The runtime cost is proportional to the cost you already had in that call tree.

layer8 3y ago

Especially for failure (as opposed to just optionality), I think that exceptions are the right approach, because in general you want to transport data and type about the failure. That doesn’t imply the traditional try-catch-finally syntax — I think we can find better syntax for typical cases — but having a distinction between a normal return (type) and abnormal returns (return types). This is like a special kind of sum type where one of the options is specially distinguished.

JonChesterfield 3y ago
Exceptions are the wrong thing. Throw an exception means "throw away the context of the failure and then goto some other function". The exchange amounts to: Something went wrong somewhere! Where? What? I knew a moment ago but threw it away for implementation convenience. Here's an object. Thanks! Fringe benefits include sacrificing linear types - the zero runtime cost, infallible way of doing deterministic resource cleanup - and embracing the mental dissonance of goto evil unless it doesn't say where it's going to. Sum types are probably the right thing.
- layer8 3y ago
  With checked exceptions, there is no difference from sum types in terms of interface contract and type checking. You’re not throwing anything away. The exception carries a stacktrace that tells you exactly where the failure was detected. The exception type and the data that the exception carries can give you all the data you might want about the failure. Exceptions can be chained (wrapped) to give additional context and/or to conform to an up-call-path interface contract, without losing any of the original information. Secondary failures during stack unwinding can be attached to the original exception (as for example Java does automatically in try-with-resources for resource cleanup), so in general you get a tree of errors that corresponds to the failures encountered in the call tree. This gives you much more information than the typical result codes/enums. The runtime cost is proportional to the cost you already had in that call tree.