[Learning Mode] Discussion: How do we best introduce case-expressions?

[kytrinyx]

The goal of this issue is to come up with a code example that can be used as the basis for an exercise that introduces case-expressions in Haskell.

A few thoughts:

• We don't have to teach everything about case expressions (and indeed, we probably shouldn't). We'd rather have several smaller exercises that build on each other than one big exercise. This gets people writing code quickly, which helps the concept to start sinking in
• We'd like to introduce this as early as possible in the concept tree, maybe right after Temperature, which introduces a couple of basic numeric types (Int and Float). But if the example code is easier to do using something other than numbers, then we can introduce another exercise first, before case-expressions.
• The code doesn't need to be ideal, idiomatic Haskell. This is a tiny stepping stone towards understanding case in Haskell, but students will quickly move beyond this into code that uses more of the language, and uses the language in ways that are more typical.

Elixir introduces case expressions with this exercise:
https://exercism.org/tracks/elixir/exercises/german-sysadmin
The example solution looks like this:
https://github.com/exercism/elixir/blob/main/exercises/concept/german-sysadmin/.meta/exemplar.ex

Is this a bit of code that would translate well into Haskell? (Would it feel like decent Haskell, or would it feel weird and foreign?)

What are some other sample bits of code that use case in a way that is potentially easy to understand for people who are new to Haskell?

[MatthijsBlom]

We don't have to teach everything about case expressions (and indeed, we probably shouldn't).

It might surprise you how easy it is to explain (essentially) everything about case expressions in Haskell. They're quite simple.

---

For reference, this is the most recent concensus on Slack (original):

Alright, so pattern matching is to be split up into two concepts, with

• Pattern Matching 1 introducing matching on integer literals and (hereby proposed by me) guards, and
• Pattern Matching 2 introducing matching on ADTs (including reminder on guards)

(Names temporary: I failed to come up with good name pairs.)

Does this sound right?

If we do this we should consider introducing custom data types/algebraic data types between the two, and Maybe in particular as it is not an enum-like type but has an optional field.

Also Either, in parallel with or directly following Maybe. Having them both as prerequisites for PM2 is not necessary but would be nice.

@pwadsworth has already worked on this PM1: the corresponding exercise is Guessing Game.

I'd like to call dibs on the explainers of PM2, as I have already been composing in my head for days. These explainers should make it obvious even to the non-Haskellers what appropriate exercises look like.

[pwadsworth]

For names, how about:

• Pattern Matching: Literals and Variables.
• Pattern Matching: Types.

The Type part would benefit of a qualifier. Simple? Basic? So is not confusing if we later want to go into PM: Lists, PM: Tuples, etc.
Although after these two concepts it would make sense to include the specifics of pattern matching with each new type introduced.

@MatthijsBlom

I'd like to call dibs on the explainers of PM2

What do you mean by 'explainers'? The concept? instructions? both? Do you want me to tackle the exercise? If so, Valentine's Day?

[ErikSchierboom]

I'm not entirely sure I follow the discussion.

Alright, so pattern matching is to be split up into two concepts, with

• Pattern Matching 1 introducing matching on integer literals and (hereby proposed by me) guards, and
• Pattern Matching 2 introducing matching on ADTs (including reminder on guards)

The guessing-game exercise has been built and covers part 1, and the valentines-day exercise that is still to be built will cover part 2. That said, this issue is about case-expressions, for which I thought we intended to create another, third exercise just for case-expressions. Did I miss anything?

[MatthijsBlom]

Way I understand it, the concept graph will look something like this.

              |
   Simple Pattern Matching      
   /          |        \
Maybe      Either      ... (tuples, lists?)
   \          |        /
    Algebraic Data Types
      ("custom types")
              |
   Pattern Matching Proper
              |

with

• Simple Pattern Matching introducing matching on literals and guards. Personally I prefer introducing case expressions here as well, and explicitly presenting the name pattern = ... as syntactic sugar for case.

• Maybe, Either, …, introducing the following aspects of these types:

  • Acting on them – see utilities in Data.Maybe, Data.Either, Data.Tuple
  • Constructing them using their constructors

  But not pattern matching on them.

• Algebraic Data Types introducing data declarations, maybe type declarations, and probably not newtype declarations. But still not pattern matching on them.

• Pattern Matching Proper introducing pattern matching on algebraic data types. Exhaustivity, recursive ('deep') matching, pattern variables, …, all the usual stuff.

---

What do you mean by 'explainers'? The concept? instructions? both? Do you want me to tackle the exercise? If so, Valentine's Day?

@pwadsworth The explainers are the about.md and the introduction.md. I have no wish one way or the other as to who does the exercise.

Did I miss anything?

@ErikSchierboom in the above-laid-out design, case expressions are tackled at the same time as pattern matching. I feel they should: 'all' pattern matching occurs in case expressions or syntactic sugar for the latter. Valentine's Day is fine.

[kytrinyx]

@MatthijsBlom I really like that concept graph, and I'd like to open a new issue with the graph as a starting point.

We have a solid exercise for the first node in the graph with the Guessing Game PR that @pwadsworth has opened (#1094), and I'd like to get that merged. We can always come back and tweak it once we have more exercises and start seeing how the bigger picture is shaping up.

I'll leave this issue on hold until we've figured out the exercises for the nodes in the graph. As you say, case expressions will likely be covered as part of that, and if so we can just close this issue at that point.