4 ms·

You can improve that code by having a single error type. Either by returning the same error from both handlers or having an error sum type which contains both e

You can improve that code by having a single error type. Either by returning the same error from both handlers or having an error sum type which contains both errors. You probably don't really care about the exact error that can be thrown by either handler, you just need enough information to display a sensible message to the user. NSError may be just enough for that purpose! After doing that, the type of Handler3 can be had as Result<Tuple<Data, Address>, NSError>, for example. And how do you combine the two results into the Tuple? That's an applicative, I'm sure swift provides combinators to do just that.

taeric 8y ago
Didn't the post you are responding to say that? I suspect you didn't read past the example. The problem comes because you have to either use a single error for two parts or deal with a tough explosion of types. No?
- masklinn 8y ago
  There are known solutions to this problem: you can type-erase to a single supertype (e.g. Error/NSError[0]) or convert from the third-party's type to a first-party type[1] for instance. [0] https://developer.apple.com/documentation/swift/error https://developer.apple.com/documentation/swift/error [1] https://boats.gitlab.io/failure/ https://boats.gitlab.io/failure/
  - KirinDave 8y ago
    It's sort of amazing that you're replying to a post suggesting something I suggested, by re-suggesting what all 3 posts prior to you suggested. But as I've said, yeah you can do this. But it's unfortunate because it destroys a lot of information that's useful in the type signature. Haskell does this with exception hierarchies and some clever runtime casting attempts, but even that has ergonomic issues. What'd be really amazing is if we could get the totality checking of pattern matching but also the composability of exception handlers, and that's what the next generation of error handling primitives are trying to do.
KirinDave 8y ago
> the type of Handler3 can be had as Result<Tuple<Data, Address>, NSError>, The combination of data and lookup is more like data(lookup(default)), which in haskell (assuming we could encode the error type neatly): load =<< lookup "default". So Result3's first parameter is of type Data. > You probably don't really care about the exact error that can be thrown by either handler, you just need enough information to display a sensible message to the user. Please consider looking for the part of the article we're discussing where it says, "However, adding that extra type information to our result type does have some nice benefits - for example, it lets us specifically handle all possible errors at the call site, like this" Ultimately we'd like to get to where the compiler can do at least a rudimentary totality check on the error handler. P.S., I know my prose is rambling and my code is overly verbose, but please consider how it makes me feel when you give me suggestions I myself discussed in the prior post.

taeric 8y ago

Didn't the post you are responding to say that? I suspect you didn't read past the example. The problem comes because you have to either use a single error for two parts or deal with a tough explosion of types. No?

masklinn 8y ago
There are known solutions to this problem: you can type-erase to a single supertype (e.g. Error/NSError[0]) or convert from the third-party's type to a first-party type[1] for instance. [0] https://developer.apple.com/documentation/swift/error https://developer.apple.com/documentation/swift/error [1] https://boats.gitlab.io/failure/ https://boats.gitlab.io/failure/
- KirinDave 8y ago
  It's sort of amazing that you're replying to a post suggesting something I suggested, by re-suggesting what all 3 posts prior to you suggested. But as I've said, yeah you can do this. But it's unfortunate because it destroys a lot of information that's useful in the type signature. Haskell does this with exception hierarchies and some clever runtime casting attempts, but even that has ergonomic issues. What'd be really amazing is if we could get the totality checking of pattern matching but also the composability of exception handlers, and that's what the next generation of error handling primitives are trying to do.

KirinDave 8y ago

> the type of Handler3 can be had as Result<Tuple<Data, Address>, NSError>, The combination of data and lookup is more like data(lookup(default)), which in haskell (assuming we could encode the error type neatly): load =<< lookup "default". So Result3's first parameter is of type Data. > You probably don't really care about the exact error that can be thrown by either handler, you just need enough information to display a sensible message to the user. Please consider looking for the part of the article we're discussing where it says, "However, adding that extra type information to our result type does have some nice benefits - for example, it lets us specifically handle all possible errors at the call site, like this" Ultimately we'd like to get to where the compiler can do at least a rudimentary totality check on the error handler. P.S., I know my prose is rambling and my code is overly verbose, but please consider how it makes me feel when you give me suggestions I myself discussed in the prior post.