On Sun, Jan 3, 2021 at 6:32 PM roger peppe <rogpe...@gmail.com> wrote:
> FWIW I'm certain that the lack of tuples in Go was a very deliberate
> decision - one of Go's more significant ancestors, Limbo, had tuples.
> Anonymous product types have their disadvantages too (you don't get to
> name the members, so code can end up significantly harder to understand),
> which I suspect is why Go didn't get them.
>
>
In a certain sense, Go already has anonymous product types! For instance:
func main() {
x := struct{ a, b string }{"Hello", "playground"}
fmt.Println(x)
}
Also, note we do get to name the members of said product members. In
Standard ML, a struct[0] is what you have in the core language and "tuples"
are more or less a syntactic sugar construction on top which decomposes
into structs. Fields are projection-accessed through their positions,
1,2,... In general I agree with you, and if you return multiple values from
a function it's important to name them. A good example is returning a
Public/Secret key-pair. Both tends to be byte-arrays of equal size, so the
types are the same and a user can easily mess them up. There are two ways
to solve that conundrum: either return a struct where the field names
describe what's in there, or mint new types so they can't be interchanged
(one can use phantom types here for added benefit).
There's an important development in the same general area of a programming
languages: row polymorphism. Here, we observe that if a function only
references certain fields in an anonymous struct, it doesn't matter if the
function gets called with a struct containing more fields. Getting this to
work is possible, though some of the resolution rules are quite unintuitive
(like subtyping in general, you tend to run into co-/contra-variance).
A good example of row polymorphism use is in the Elm programming language.
Web programming often requires you to "glue" different parts together and
Elm's "Extensible Records" are exactly row polymorphism. It allows the
programmer to build functions which only require a small part of a larger
structure to operate, and the larger structure to evolve independently of
the functions. It can remove a lot of the chore of going around and doing
type-level mechanical fixup[1]
> People will even realize that when you compile this, you don't have to
> pass a pointer to said tuple but can make a choice on calling convention
> which passes such tuples in registers to speed up the system and be as fast
> as any other language.
>
> I believe that the new register calling convention will do this for
> structs FWIW.
>
>
Yes! See above as to why. Structs are isomorphic to tuples if you mod out
naming.
[0] In Standard ML, they are called "records", though they are more or less
equivalent to structs.
[1] Essentially, this is what refactoring tools automate.
--
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/CAGrdgiV0pgf1dScxeuFHLbcxFEH26eOhffzEWwM2wR2%3DQFiHSQ%40mail.gmail.com.
