let Expressions

[00:00:00]
>> Richard Feldman: Now we have introduced a little bit of code duplication here. Which is a little bit annoying. We're using String.fromInt quantity ++ space, and then plus plus, the interesting part. So let us resolve that code duplication. There is a bunch of different ways we could do it, but I'm going to choose to resolve it in a particular way that demonstrates some new concepts.

[00:00:17]
Specifically, a let-expression. So here's how we could, one way we could do this using a let expression. Probably I wouldn't quite do it like this in reality, but this demonstrates some useful concepts, so we'll choose to do it this way for the purposes of demonstration. Okay, this right here is a let expression.

[00:00:35]
It's got let, it's got in, and it's got some stuff in between, and it's got some stuff after. Let's kinda walk through the different things that are going on here. So we're defining two new values here, quantityStr and prefix. And these are two new values that are only accessible inside the let expression.

[00:00:54]
You can see that they're based on one another, so quantityStr is immediately used by prefix and then down below, we end up using prefix in the ultimate expression that we are using. So, those are only available inside the let expression. They are completely inaccessible to the outside scope.

[00:01:15]
So, any other function outside pluralize that wants to access them cannot. These are scoped to inside the let expression itself.
>> Richard Feldman: The entire let expression evaluates to this. So between let and in, we can define various different values if we want, as many as we want or as few as we want.

[00:01:34]
We can only have just one if we wanted. And then at the end of the day, all of that is gonna get substituted for what we defined down at the end here so this is sort of the meat of what the let and in is evaluating to. Everything above is just in support of the thing that comes after in.

[00:01:50]
And just like if, let is an expression we can say X equals let blah blah blah in etc. And the entire let expression's going to evaluate to a single value. One quick note on syntax, there are two places in Elm where indentation matters, this is one of them.

[00:02:06]
The way that Elm knows where one value begins and the next one ends is by looking at the indentation. You can choose whatever indentation level you want here, of course Elm format will pick one for you. But these do have to have the same, however many of these you put inside the let, they all have to be indented to the same level.

[00:02:23]
>> Speaker 2: So could you, it's kinda weird, but could you refer to prefix in quantity string? Do they have to be, are they evaluated in order?
>> Richard Feldman: Great question, yeah. So are they evaluated in order? So, the short answer is that, how do I explain this without getting into stuff we haven't gotten into yet?

[00:02:48]
[LAUGH] Generally speaking, order does not matter with the things inside a let expression. However, if you have them refer to one another, that's gonna be a problem because they need to be able to, one needs to be resolved but without the other, or else we have mutual recursion and that wouldn't compile.

[00:03:10]
However, if we were to, for example, take the definition of prefix and move it above the definition of quantityStr, that actually would work out okay. The reason that it's safe to do that and that'snot going to cause any problems, has to do with some characteristics of Elm that we're not gonna get to for another couple of parts, but short answer is, you can't reorder them as much as you want.

[00:03:29]
>> Speaker 2: Is that bad practice and, okay.
>> Richard Feldman: Not at all. I don't even think about order, honestly. [LAUGH] Yeah.
>> Speaker 2: It couldn't cause a bug or something?
>> Richard Feldman: No,
>> Richard Feldman: I'm trying to think if there's any possible way you could cause a bug with ordering, and I really can't think of any.

[00:03:51]
>> Richard Feldman: Yeah, no I'm comfortable making the claim that you can't cause a bug by doing that, at least not in production. It can only affects debugging tools, that's the only case I can think about where there would be any difference at all. Like as far as the production bug, I don't think so yeah.

[00:04:09]
>> Speaker 3: Can you nest let-in expression?
>> Richard Feldman: Absolutely, yeah. Great question. So any time you want, you can just, anywhere you have any expression in Elm, you can be like, you know what, I'm gonna take this sucker out and I'm gonna replace it with a let. Absolutely fine. You can nest lets inside other lets.

[00:04:24]
Let is sort of this all-purpose, like, I need to name some stuff in a new scope. There’s a lot of places where Elm doesn’t bother creating implicit new scope for you, because it’s just got, let, that you can put anywhere in there to solve that problem. So yeah, definitely.