Creating Constraints Solution

[00:00:00]
>> Richard Feldman: Let's go through these. So, we have a problem that all of these are tasks, and we want them to be commands. So, we'll go over here and build it, and unfortunately, the type mismatch that we're gonna get here, although it is correctly telling us that these don't line up.

[00:00:14]
The particular thing that it's complaining about, is not giving us a super great clue as to what the real problem is here. What it's complaining about is the sort of preliminary problem it encounters, which is to say that, these are all different types that are all in the list literal.

[00:00:30]
So, the problem that it's complaining about is like ,hey, the second element is something, is a task that returns, yeah, an HTTP error, but a list of comments. But the next task in the list, has a different success type. So it's complaining about something that is sort of unrelated to what we want.

[00:00:50]
What we actually care about is the fact that, yeah, but we're passing this whole list of alleged commands to command.batch but they're not commands, they're tasks. Nevertheless, this does give us at least the information that we need to figure out where to get started. So what it's telling us is that the first element has the type Task Http.Error (Article Full).

[00:01:09]
And the second one has a type Task Http.Error (List Comment). So based on that, we can see, well, clearly, this is not going to unify with Never. Both of these could potentially have HTTP errors, which is to say that we're not gonna be able to use Task.perform with either of these.

[00:01:25]
We're gonna have to use Task.attempt. So, if we look at the docs for Task.attempt, it's gonna tell us that we need to provide a message that accounts for the two possible outcomes. One that it succeeds, and the other that it fails. In order to do that, it's gonna have them wrapped in a result, which means that, when we want to call a Task.attempt.

[00:01:50]
We're gonna have to give it a message that get has a result that handles the Http.Error for the error case and then for the success case whatever the particular thing is that each of these tasks produces when it succeeds. So to figure to that out, we're gonna go take a look at our message type, and we're gonna look for something that lines up with these.

[00:02:07]
We're gonna look for something that is a message that holds on to a result of Http.Error and Lists Comment. And that's gonna be, but one for the second one and for the first one, we're gonna want Http.Error and (Article Full). So let's see if we got anything in here, we'll go shopping for messages and see if we spot anything that looks good.

[00:02:25]
So here's something that looks pretty good, CompletedLoadArticle. It's got exactly the type we want, result Http.Error (Article Full). So we're gonna try that out as our type for the first thing. Task.attempt CompletedLoadArticle and for the second one this is the list of comments. That's got the same thing but an Http.Error is gonna be paired with List Comment instead.

[00:02:48]
So let's see if we can see anything in there, and sure enough the next one is CompletedLoadComments. So we're gonna do that over here, Task.attempt. CompletedLoadComments, okay, now let's see what it complains about. Okay, now we see a new error. So, its still complaining about the list being incongruous about the elements having different types.

[00:03:08]
But this time it's saying hey the problem now is that, this third one, is a task that produces no errors, interesting, interesting. And the previous ones are all commands, which is now true because we made those both go into commands. Since this one is producing a task that cannot possibly have an error, we can safely use Task.perform on it.

[00:03:30]
>> Richard Feldman: What are we gonna pass to task.perform? Well, it doesn't expect a result because there's no possibility that it could fail. So we're really just looking for something that accepts a Time.zone value inside our message. So we go shopping for one of those and here we go GotTimeZone Time.Zone.

[00:03:45]
Fair enough, okay. Last but not least, we see SlowThreshold is a task that takes task with actually, not only does it have no error type, but also on success it produces a unit which is to say nothing. Nothing of any use whatsoever. But we wanted to convert it into a message.

[00:04:06]
So for that one, we can definitely safely use Task.perform. And what we're gonna look for is a message that takes a unit and then returns a message. So let's see if we have anything like that. We actually don't. We don't have any of these that fit that exact description.

[00:04:28]
What we do have, is this thing whose name matches what we want we want, the PassedSlowLoadThreshold. But, I think quite reasonably, this doesn't hold onto a unit because unit doesn't tell us any information. It just says, yeah, this is a message with no additional information. We passed the slow load threshold.

[00:04:44]
That happened, I have no further information to give you about what happened. It's just we did it. So the way we can handle that, is that, we can rather than passing in the variant function like we did in all the other case, we can just pass it in an anonymous function, that says, just always return PassedSlowLoadThreshold.

[00:05:01]
Or, if we wanna get a little bit more explicit we can do this, which essentially says I am not only ignoring this, but I am pattern-matching on it and saying it has to be unit, which is to say it has to be this value with no meaning. This is similar to when we, a couple of exercises ago, did preview in the pattern match, to say, I know that this is exactly what this is.

[00:05:20]
It is definitely something that has no information. Also, I think quite important to note, is that this thing right here, looks like a dude doing a karate type of motion, so that's pretty cool. Questions about all of these? Yeah, let's confirm they actually compile, they do.