Add Custom types concept and associated exercise

[ceddlyburge]

No description provided.

[mpizenberg]

While reading this I realized that this concept does not talk at all about type variables. So I've re-read the previous exercises about list and records and they also do not talk about type variables. I think it could make sense curriculum-wise but especially in list, it should be noted that we do not explain type variables.

Small digression about the List concept exercise and type variables

If we indeed delay the explanation of type variables, it is important in my opinion in the template src/TracksOnTracksOnTracks.elm to add a type annotation to all functions. For example

newList : List String
newList =
    Debug.todo "implement this function"

Otherwise, the List a expected type annotation would be confusing. And by the way, we don't check in the tests that newList works with other list types.

Alternatively, we could introduce briefly type variables, just like I do in the Maybe concept. Not going into the details, but since just like Maybe, the List type can only hold one type variable, we don't have to explain those in their full. But still I think we should mention that simple case of type variables in the List concept. That will also help students read the docs for List in the package website.

Then it can make sense to ask students to write the type annotations (I'm not even sure), and to check in the tests that newList for example also work on something else than strings? (again not sure because there isn't really a point doing that for that exercise)

Back to this concept

So now the question is do we explain type variables for custom type? I think it's a good choice to delay them indeed. We can have a generics and polymorphism concept later that would depend on list, maybe, record, and custom-types. And in that later concept go into more depths with type variables.

Regarding the exercise

I'm feeling we miss a task for students to create values of a custom type, not only define them. Maybe we could add

genreFromString : String -> Maybe Genre

Then we just have to set the maybe concept as a dependency. Which wouldn't be far fetch. It would be a simple first exposure to custom type without explaining all (just enough for Maybe), then expand that comprehension with the custom-types concept.

---

Let me know what you think of all this!

[ceddlyburge]

I'm feeling we miss a task for students to create values of a custom type, not only define them.

rateActivity returns a custom type, which the student must define. It doesn't have any associated data though.

[ceddlyburge]

I think it is probably good to mention type variables here, I think the dependency tree might start to get super tangled otherwise. And Maybe is a custom type, so it's strange to make it a pre requisite.

Having this and then another concept for "custom types with type variables" could make sense though.

If we add type variables to this concept / exercise, maybe we can change the approval type

type Approval a
    = Yes a
    | No a
    | Maybe a
    | WouldPrefer a

This might also be an opportunity to introduce a requirement for the student to create a more complicated type. For example if Movie Horror is proposed, WouldPrefer (Movie Thriller) should be returned.

[ceddlyburge]

If we indeed delay the explanation of type variables, it is important in my opinion in the template src/TracksOnTracksOnTracks.elm to add a type annotation to all functions.

This probably makes sense anyway, so I've added it. I made the commit in the 'records-concept' branch by mistake though. I can cherry pick it here if you want.

[ceddlyburge]

I think that is all the comments addressed, although obviously there is still some discussion to do! Let me know what you think!

Cheers, Cedd

[mpizenberg]

And Maybe is a custom type, so it's strange to make it a pre requisite

Well we learn to count before learning that Z together with addition forms a group where 0 is the identity element. Maaaybe the comparison is a little stretched but that's to say that people learn well by example and then generalization. So it would not be too strange to me to first learn about Maybe and then generalize with all custom types. But's adding type Maybe would be confusing anyway since we already have a Maybe variant in this exercise (should we change it to some other name to avoid confusion?).

rateActivity returns a custom type, which the student must define. It doesn't have any associated data though.

Right, forget what I said ...

type Approval a = Yes a | ...

I don't have a good feeling on this one. It's not super valuable. Let's leave generics and advanced type variables for later.

I made the commit in the 'records-concept' branch

Yep that's fine

[mpizenberg]

Rebased on main to fix configlet.

[ceddlyburge]

Well we learn to count before learning that Z together with addition forms a group where 0 is the identity element

This made me chuckle :)