Tuples

[00:00:00]
>> Richard Feldman: Talking to servers. So we'll start off by talking about all of these things at once I guess. [LAUGH] Tuples, randomness, commands and http. Start with tuples. So tuples fundamentally serve the same purpose as records. Anytime you have a tuple, you could also have had a record and they would serve the same purpose.

[00:00:23]
All they really do is they're sort of more concise than records because instead of using field names, they use field positions to describe their fields. So give you an example, here is a tuple, that's 5, 7. We could say x = Tuple.first, and that'll say, okay x is 5.

[00:00:44]
We could also use this syntax to define the contents of a tuple. This is what's known as destructuring syntax. So we could say ( name, x, y ) = again ( "foo", 5, 7 ). And that's going to say foo goes into the name slot, 5 goes into x and 7 goes into y.

[00:01:03]
So now I have name, x, and y all in scope, and they have the corresponding values to this tuple. Now, as you can imagine, we could very easily have done this with a record. We could say x = and then the record name .x. That's totally valid. But again, tuples serve the same purpose as records, it's just that here we have this done by field order, we didn't actually specify a name of x and y, and here we have the fields that are actually named.

[00:01:31]
That's the difference between tuples and records. The larger example converting to a record can be done the same way. You can use this curly brace syntax to destructure records in the same way that you can tuples if you want. The only difference is that, in the tuple example, name, x, y, refers to the positions, whereas in the record example, it actually needs them to have the same name as whatever's in the record.

[00:01:57]
So name, x, y, in this case refers to the field that is named x, and the field that is named y. But because of that, in the tuple version, you need to, if you're destructuring them, specify every single one of the fields in there, whereas in the record version you do not.

[00:02:16]
You can put them in any order and you can only specify some of them if you want and leave others off, that's all totally fine. One other quick note is that tuples have a three element maximum. You can't have tuples of more than three elements, because at that point, let's be real, you ought to be using names.

[00:02:32]
That's just like too much in a row. So there's, that's just enforced by the, sort of a language decision. There's no technical reason that it couldn't be more than 3, in fact, it used to be more than 3, but then, basically, like, you know what, probably if you're using more than 3, something's gone wrong somewhere and it's time to start naming things.

[00:02:52]
Okay, so both records and tuples in L are nothing more than groups of values that travel together. Right, if I say I wanna call a function called animate, I could pass it like name = "foo", x = 1, y = 3, and maybe it's gonna do something with those values to animate something.

[00:03:08]
I could also parse it a tuple, either way animate is getting the same information, it's getting the same string and the same two numbers, just in a different format. Also I could just pass it as arguments, that's also totally fine. All of these, essentially, are not going to change the underlying behavior, they're just three different ways of specifying the information that we want to pass to animate.

[00:03:31]
Now I mentioned this because this is different from say JavaScript objects where potentially the record could have a prototype, and it could have this, it could have methods that are doing things based on the identity of what you're passing. But in Elm, all three of these, are essentially equivalent, there's really no difference except in sort of the ergonomics of the design.

[00:03:50]
In terms of the fundamental characteristics of what we're doing, we're doing the same thing in all three cases. It's just that sort of we want to have a convince of having these values travel around, in some cases where they're related, and it's more convenient to have them travel around as opposed to having to pass them one by one as arguments to a particular thing.

[00:04:09]
Having said that, custom types can be much more than just values that travel together, they can have custom shapes, they can have data that fits different characteristics, and we'll talk some more about that in the advanced course.