[theoh]

Sum types arguably permit a form of out-of-band return value. A function that returns a sum type has the choice of returning the usual type (an integer value, say) or an error value of some other type.

IMO this counts as a kind of out-of-band arrangement because it doesn't involve using one of the normal return values to signal error.

https://en.wikipedia.org/wiki/Semipredicate_problem

[chucksmash]

But are you actually returning either an int or an error? You're always returning a Result type which may contain either an int or an error.

[theoh]

In Haskell one applicable type is actually called "Either a b".

I'm not sure what your point is. If a function has a "unitary" return type (not, say, a list of possible return types out of which one is selected) then obviously it always returns a value of that type.

You could probably invent a kind of function that had a list of possible return types. Then anyone who called it would have to deal with those possibilities.

It all comes to the same thing in the end. Sum types and pattern matching are a very good system for expressing this functionality.

It's conceivable that a compiler would throw away the Either type information and just generate separate code for the different ways the function might return. Ultimately, though, I suppose it would end up calling a continuation, since the function has to "return" somehow.

[chucksmash]

I was replying to this:

> IMO this counts as a kind of out-of-band arrangement because it doesn't involve using one of the normal return values to signal error.

My point is that if you're returning an algebraic data type Result that encodes Ok(val) or NotOk(_), you are using one of the normal return values, because the function always returns a Result. The whole purpose of the construct seems to me to be bringing the error case handling into band.

[theoh]

The way I see it, each of the data types in a sum type is analogous to a channel. The type of the 'message' conveyed by a value is effectively "Either Control Data".

In-band signalling is messier than out-of-band signalling, so I see out-of-band as the goal. If you look at the various approaches to the semipredicate problem on that Wikipedia page, it looks like, historically, we started out with awkward in-band solutions and the evolution is towards the clarity offered by expanding the return type to send errors out-of-band.

I mentioned this previously on HN, and maybe that earlier comment will clarify what I'm talking about: https://news.ycombinator.com/item?id=18766478

pjc50's way of applying the terms to flow of control is a somewhat different thing.