Usually, the type theoretic basis is what is called a sum-type. They are
corresponding to a logical OR or a '+' addition operation in algebra. A
"struct" is rightfully a variant of a product-type, or a logical AND or a
'*' multiplication operation in algebra[0]. Most (commonly used)
programming languages can "multiply" in the type system, but they can't
"add", and this creates a lot of serious problems since you have to
simulate sums through products.
If we write
type point struct {
x int
y int
}
you could argue that a value of type point contains "a value X" AND "a
value Y", which is why they are often called product types. Forming a point
point{x,y} mandates you supply both at the same time.
For sums, in Go, I have to return a pair,
x, err := someOperation(..)
but this is slightly inconsistent, insofar I can return "nil, nil", which
might not be a valid value, or I can return "3, Error(..)" but in that case
the 3 is not to be used. Only one "side" is valid at a given point in time.
If you have sum-types in the usual sense, you can define something along
the lines of (OCaml follows):
type ('a, 'b) result = Ok of 'a | Error of 'b
And then you can discriminate on this value via pattern matching
match res with
| Ok value -> ...
| Error err -> ...
This means that the inconsistent state cannot be represented. An ('a, 'b)
result is either "Ok ..." OR "Error ..." but it can't be both.
Go does have matching constructions which are special cases of the general
variant above. In particular, in OCaml we can have
match x with
| true -> ExprT
| false -> ExprF
(where ExprT/ExprF are arbitrary expressions) but this is same as (in fact,
syntactic sugar for):
if x then ExprT else ExprF
which is roughly equivalent to the following in Go[1]
if x {
ExprT
} else {
ExprF
}
The other matching construction is a switch-statement, but such a statement
doesn't allow for matching deeply into an AST structure, which a
traditional pattern matcher does.
In practice, a programming language will contain a "pattern match compiler"
which compiles a pattern match into an if-maze, a jump table, binary search
and so on. This means they are efficient to execute in practice because you
can use positive and negative match information to skip match clauses when
needed. Two good references are Simon Peyton Jones compiler book[3] and
Peter Sestofts pattern match compiler[4]
Coincidentally, given sum-types, you can write a regexp matching engine in
very few lines of code. See Bob Harper's "Programming in Standard ML" [2]
for example; it is the introductory example to get a feel for the language.
The solution uses sum types to define the AST for regular expressions, and
then uses pattern matching to build a matcher on regular expressions. I
can't remember how far Bob takes the exposition however.
Rust calls them "enums" but they are more than just an enumeration in e.g.,
Java, because each variant also binds values. Scala calls them sealed
classes, and I guess it has to do with the language being heavely based on
Java and thus needs the concept to coexist with subtyping, but I may be
wrong in my guess.
[0] They are really the same in the right setting. In a boolean algebra,
for instance, + is OR and * is AND. If you look at them from the Category
Theory branch of mathematics they are related: they are duals of each other
which means that if you "invert" one you get the other and vice versa.
[1] Obviously, Go, being a descendant of Algol has two syntactic classes:
statements and expressions, whereas OCaml is descendant from either Lisp or
the Lambda Calculus depending on view. Those languages only have
expressions as a syntactic class.
[2] http://www.cs.cmu.edu/~rwh/isml/book.pdf
[3]
https://www.microsoft.com/en-us/research/wp-content/uploads/1987/01/slpj-book-1987-small.pdf
[4] http://dotat.at/tmp/match.pdf
On Thu, Feb 22, 2018 at 1:14 PM Josh Humphries <jh...@bluegosling.com>
wrote:
> On Thu, Feb 22, 2018 at 4:56 AM, Steven Hartland <ste...@multiplay.co.uk>
> wrote:
>
>> On 22/02/2018 09:46, andrewchambe...@gmail.com wrote:
>>
>> Just a list of things I like about Go, thanks everyone for the hard work:
>>
>> snip...
>>
>> Minor things that could be improved in order of importance:
>>
>> - Ways to express immutability ... as a concurrent language it can still
>> be easy to make mistakes and share a buffer or slice by accident.
>> - More advanced static analysis tools that can prove properties of your
>> code (perhaps linked with the above).
>>
>> Have you seen: https://github.com/alecthomas/gometalinter
>>
>> - Generics.
>> - Some sort of slightly more sophisticated pattern matching .
>>
>> Not sure what you mean here but have you seen:
>> https://golang.org/pkg/regexp/
>>
>
> I'm pretty sure Andrew was referring to pattern matching like in Scala and
> Rust. It's a very slick feature. Related: Rust's enum types are slick --
> they are like a combination of enums (such as in Java, and Scala) and
> Scala's sealed classes.
> https://docs.scala-lang.org/tour/pattern-matching.html
> https://doc.rust-lang.org/1.6.0/book/match.html
>
>
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
--
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.
For more options, visit https://groups.google.com/d/optout.
