On Mon, Jun 10, 2019 at 8:11 AM Michael Jones <michael.jo...@gmail.com>
wrote:
> I miss discriminated unions too. (Fancy new name, “sum types”).
>
They are called sum types because they work as an "addition" like
construction in the type theory. Their dual, product types, are what people
usually call records or structs in many languages. Structs work as
"multiplication" in the type theory.
For some reason, many languages in the mainstream can multiply at the type
level, but they cannot add. It looks like the newer generation, Rust,
Swift, ... start looking into these in earnest as additions, and this is
welcome.
There are some interesting corollaries from having sum types:
There is no boolean anymore. A boolean is simply
type bool = true | false
and you can also remove the if-statement from the language since the
elimination form,
match x with
| true -> ExpT
| false -> ExpF
is essentially an if-statement. Having to add something like match seems
odd, but it isn't! It's dual is the projection operation '.' on structs.
Suppose
type GeoPoint struct {
Lat, Lng float64
}
var gp GeoPoint
then `gp.Lat` is the elimination form.
Next, there is no need for a null value anymore:
forall 'a.
type 'a option = None | Some 'a
Granted, you need polymorphism as well here, but once you have this, you
can remove the concept of null for the value 'none'. Thus, the default in
the language is that no value can be null, unless you wrap it into an
option. Continuing, you can define
type ('a, 'b) result = Ok of 'a | Error of 'b
which is a clean way of returning errors from functions. In Go, we have to
return a product pair such as `return v, nil` or `return nil, err`, but of
course, people forget to check the error. With a sum, that kind of mistake
cannot happen, since you are forced to match on the erroneous case. This is
also what leads you to have programmable control flow eventually; what
people call a whole slew of things: monads, applicatives, ... The recent
`try` proposal for Go 2.0 is an extreme special case of this, where control
flow is specialized to the above situation.
Personal bet: over time, mainstream languages will get sum types, at least
in a limited form. It is as if programmers are writing expressions in a
logic where they have && (AND) but no || (OR). You can do it because you
have if-statements, but it gets really tedious to write. At some point, it
is going to be "generally accepted" at which point languages without sum
types are going to be regarded as a relic of the past. Also, it rounds out
the logic of the programming language, and makes it internally consistent.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiXxRPWEZbFhz022Rt8Hre%2B_-re8wG1ERGO%3DcFK_rfMuEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
