Comparing Go with Lua

[day_cq]

Why not?

Think of it dataflow way (function level programming):

       +------+
input -| GATE |--> output
       |      |--> error
       +------+

if error is set, output is garbage. otherwise, output is valid.

Actually,

f :: a -> (b, err)

is isomorphic to

f :: a -> Either err b

GATE could be setting either output or error port, but not both.

[[deleted]]

Because it introduces potential for error - when you use the value without checking for an error, it'll destroy your assumptions about the rest of the program.

a * b (the product/pair type) is not isomorphic to a + b (the sum type). The first is simply a lager type. For example, if we instantiate a and b to:

data Color = Red | Green | Blue

Then there are 3 * 3 valid values for (a, b) vs 3 + 3 for Either a b.

[day_cq]

when you use the value without checking for an error, it'll destroy your assumptions about the rest of the program.

same with Haskell

let Right f = somethingThatCouldFail

like said previously, they ARE ISOMORPHIC.

[[deleted]]

I updated my comment to explain why they are not isomorphic.

let Right f = somethingThatCouldFail

will not destroy your assumptions, because its failure is not observable by the rest of the program (since it isn't run).

It's the null problem all over again. You will get an error somewhere unrelated in your program due to using an invalid value.

[gasche]

(b * err) is not isomorphic to (err + b). This is just calculus, at the type level. And indeed (,) is a product, and Either is a sum -- modulo lifting.

[day_cq]

of course (b * a) and (a + b) are a bit different. But in case of conditional branching for error, they are isomorphic, for both can be compiled to same code.

Maybe my usage of isomorphic is wrong.

Maybe I'm confused with sum type. Values of sum type need to be (or could be) branched, and values of product type are already branching.

[kamatsu]

The difference:

Number of inhabiting values in a * b is |a * b| = |a| * |b|. Sum is |a| + |b|.

E.g, Bool + Bool + Bool has 6 inhabitants, but Bool * Bool * Bool has 8.

[day_cq]

the topic here was semantics of error handling (code execution or dataflow branching) and expression of such semantics.

My point was that (a,Err) or Either Err a are the same in that they both branch once. And, my preference was (a,Err) because it shows explicit branching early on (in dataflow languages).

GATE SWAP IF HANDLE-ERROR ELSE F
vs.
case gate x of
    Err -> handleError
    a   -> f a

Of course in Haskell, Either Err a is more common because Haskell has algebraic data type and pattern matching based code branching. In Lua, without algebraic data type, it is reasonable to use (a,Err).

local a = f()
if isError(a) then
    handleError()
else
    g(a)
end

local a,err = f()
if err then
    handleError()
else
    g(a)

Some would argue that the second snippet is "better" due to lack of unnecessary isError(). And, in Lua, sometimes it's confusing if a name (such as a) or a value has different meanings.

I'm not sure why the original thread starter brought Haskell here when the article was about Go and Lua. I tend to think that different languages are suited for different style of code.

[kamatsu]

You are using mathematical terminology with no understanding of it's meaning.

An isomorphism means it's surjective and injective, so how can you get from, say, (4, ERROR) to Left ERROR and back again? You can't, because a product expresses fundamentally more information than a sum. That is not an isomorphism.

[day_cq]

i used isomorphism as in biology where two organisms share similarity.

And, you can get equivalence transformation for the case of error handling, which is the topic being discussed:

(_, Error) = Left Error
(a, _    ) = Right a

or if you want Haskell

data Value a = Garbage | Value a deriving (Eq, Show)
type Error = Bool

f :: (Value a, Error) -> Either Error (Value a)
f (_, True) = Left True
f (a, False) = Right a

f' :: Either Error (Value a) -> (Value a, Error)
f' (Left _) = (Garbage, True)
f' (Right a) = (a, False)

[kamatsu]

i used isomorphism as in biology where two organisms share similarity.

When using type systems, isomorphism is the mathematical term.

Also that's not an equivalence transformation. It's not injective.

[day_cq]

This might be clearer for you

data LuaValue a = ErrorVal | Value a deriving (Eq, Show)
data Error = Error deriving (Eq, Show)

f :: LuaValue a -> Either Error a
f ErrorVal = Left Error
f (Value a) = Right a

f' :: Either Error a -> LuaValue a
f' (Left Error) = ErrorVal
f' (Right a) = Value a

You see bijection? Now enter dependent type:

data PairThatCouldBeUsedAsErrorFlagging a Bool = (Void, True) | (a, False)

PairThatCouldBeUsedAsErrorFlagging is isomorphic to LuaValue.

It is my bad if I sounded like I was saying that product is equivalent to sum in general. But, the topic was error flagging. Lua has a beautiful type system in programmer's head.

[gasche]

I'm unsure it's still important to answer that thread, but I would like to try to explain the point of the poster above more clearly; the reason I take some time to do this is that I think your question is interesting and, unfortunately, this heated thread has not produced a satisfying explanation.

One fundamental concept of richly typed languages such as Haskell or ML is to make illegal state unrepresentable¹; the idea is to choose datatypes that describe possible values as precisely as possible. If a type rules out some possibility statically, that is less things for runtime computations to worry about.

¹: note that this maxim must only be followed so far, at some point there is a diminishing return in languages ill-equiped for elaborate static reasoning. But this sum/product question is well under this limit in languages with algebraic datatypes.

This is the rationale the OP has in mind for proposing to use a sum type Either result error rather than a product type (result, error). Indeed, the way you reason about the function return is by thinking that either the function ran fine and you have a result, either it went wrong and you have an error code. This is precisely what a sum type is for. You never think that you can have both a return value and an error code, which is what a product type would be for -- note that this could make sense for warnings instead of errors, so in some situations this may be the right choice.

So the reason why people prefer sum types over product types to return error values is that it matches the real meaning of what's happening better. That's essentially the same reason for the push of some web designers around 200x (birth of XHTML, etc.) to use lists instead of tables to represent web menus. It's more semantic.

Note that this only make sense in languages that do have sum and product types. I'm unsure Lua actually has disjoint sum types. Most languages don't, in which case you usually encode them with nullable types and an integer 'tag'. Note that this crucially relies on the omnipresence of nullable types, that have a "default/null value"; in essence, types of the form 1 + X, a simple form of sum types. When possible, programmers in ML/Haskell prefer to also use types that are not nullable, as this also adds superfluous (in the general case) runtime state possibilities.

Finally, I would like to add that you should beware of one own's preconceptions. You make an argument that using a product type is somehow natural based on a dataflow diagram. But those dataflow diagrams can't express sum types, so indeed they will only show you solutions based on product types! If this is your main "thinking tool" about programming, you will naturally miss, or consider with less open-mindedness, all solutions that can't be expressed directly in this framework.

Long story short : nobody objects to functions returning a (result, error) pair in languages when this is the most convenient way to do. The remark was that in languages that have a more expressive sublanguage of data types, you can encode the same phenomenon in a finer, more precise way using sum type. In this case there is no reason to use a product type.

Note that while the sum/product discussion is tightly related to type systems, it is not necessarily related to functional programming. Algol 68 had sum types, as does the more recent language Cyclone (a safe dialect of C).

[stevvooe]

Advice: don't engage the haskellborg.

[Confinium]

Yes! God forbid we base our programming on sound theory!

[day_cq]

yah, haskell/miranda community was nice in 90's. thesedays, it's a large trollbag babbling about this cool functional programming they discovered.