Merge pull request #7164 from lukeasrodgers/typofix-tutorial-exit-i32

Typofix type signature for `main` in tutorial

www/content/tutorial.md

@@ -1691,15 +1691,15 @@ high-quality programs handle errors gracefully. Fortunately, we can do this nice
 If we wanted to add the type annotation to `main` that Roc is inferring for it, we would add this annotation:
 
 ```roc
-main : Task {} [Exit I32, StdoutErr Stdout.Err, StdinErr Stdin.Err]
+main : Task {} [Exit I32 Str, StdoutErr Stdout.Err, StdinErr Stdin.Err]
 main =
 ```
 
 Let's break down what this type is saying:
 
 - `Task` tells us this is a `Task` type. Its two type parameters are just like the ones we saw in `Result` earlier: the first type tells us what this task will produce if it succeeds, and the other one tells us what it will produce if it fails.
 - `{}` tells us that this task always produces an empty record when it succeeds. (That is, it doesn't produce anything useful. Empty records don't have any information in them!) This is because the last task in `main` comes from `Stdout.line`, which doesn't produce anything. (In contrast, the `Stdin` task's first type parameter is a `Str`, because it produces a `Str` if it succeeds.)
-- `[Exit I32, StdoutErr Stdout.Err, StdinErr Stdin.Err]` tells us the different ways this task can fail. The `StdoutErr` and `StdinErr` tags are there because we used `Stdout.line` and `Stdin.line`. We'll talk about `Exit I32` more in a moment.
+- `[Exit I32 Str, StdoutErr Stdout.Err, StdinErr Stdin.Err]` tells us the different ways this task can fail. The `StdoutErr` and `StdinErr` tags are there because we used `Stdout.line` and `Stdin.line`. We'll talk about `Exit I32 Str` more in a moment.
 
 To understand what the `Exit I32 Str` error means, let's try temporarily commenting out our current `main` and replacing
 it with this one: