Introduction to Elm, v2 Manipulating Values Review & Q&A
Transcript from the "Manipulating Values Review & Q&A" Lesson
>> Richard Feldman: So to recap the things we've talked about here, first, we talked about strings and how you can combine them. So if we say the letter "d" ++ String.fromInt 6, that will give us the string d6. If we have a let expression, we can say, let x = 5 in x * 2.
[00:00:17] We can put as many different values that we want inside that let expression. The entire expression evaluates to what comes after in. We saw some stuff with lists, in particular list.map, which is a useful way to transform a list of one item into a list of another items.
[00:00:34] So we saw how we can use that with numbers, with strings, and even with virtual DOM nodes. Also lists have to have a consistent type which prevents run time exceptions that can otherwise occur. And finally, we saw a partial application. We saw that when we called pluralize passing "leaf" and "leaves".
[00:00:48] That gives us back a new function, which accepts the final argument that pluralize wants and sort of finishes the job. And as we'll see later, partial application and List.map and things like that can be pretty useful together. Any questions about any of this before we get to the exercises?
>> Richard Feldman: Yes.
>> Speaker 2: I have some kind of somewhat related generic questions on some of this stuff. So List.map, I'm just curious that some languages, they'll have a generic map. And in Elm, everything kind of has its own.
>> Richard Feldman: Yes.
>> Speaker 2: I'm just curious what's the difference or decision there?
>> Richard Feldman: Some languages will have a generic map, whereas Elm has a special purpose one. So this is really a question of name resolution. So in some languages, you'll have, syntactically, you'll just say the word, map. You won't say List.map or Set.map, or whatever the data structure is. In both cases, they have different implementations under the hood.
[00:01:53] They may have been arrived at using different amounts of code sharing. But fundamentally, if you're going to have a map function that works on a list, you're gonna have a different map function that works on a set, cuz those are different data structures. In Elm sort of the style is encouraged is to write everything out explicitly and say like this is a List.map.
[00:02:10] It's gonna work on a list. This is a Set.map. It's gonna work on a set. Whereas in other languages they have different name resolution mechanisms that potentially let you just say map and then maybe you're passing in a sent, maybe you're passing in a list. But it may be even in the same module.
[00:02:25] But basically the reason for this is is it's sort of a has to do with sort of the design sensibilities around Elm. So, as an example like Haskell's a language where it's a different design set. It's like in Haskell it's encouraged to only use a map and Haskell supports that.
[00:02:41] Elm's compiler was written in Haskell but Evan decided to go a different direction than that.
>> Richard Feldman: No, no-
>> Speaker 2: We said, no, the compiler knows, okay, I have already checked, so it can just be an array under the hood.
[00:03:51] The compile checks are enough.
>> Speaker 2: So are there any things like that that it compiles to where like newer language features or something are gonna. I'm just kinda curious if browser target is a thing that we would ever want to care about with Elm cuz we would get less, or something?
>> Richard Feldman: Browser target is a thing that you would care about within Elm. Sorry, I don't really follow that. [LAUGH]
[00:05:38] So backwards compatibility is something that Elm takes pretty seriously as far as browsers go. And generally the design is to try and make it as compatible as with as many older browser features as possible, sort of by default. And not to use any newer browser features, unless there's really no other alternative to get that particular thing done.