A simple custom type instead of Maybe. Am I doing this right?

Show and Tell
4

I think in this situation it’s not really an improvement, but that’s also because your List models both “Empty” and “One or more elements” which overlaps with your NoEntries.

If you don’t mind i would just focus on one example were custom types (hopefully) improve code compared to using Maybes:

One situation where custom types shine compared to sticking Maybes in the model is when it comes to multiple connected values. Perhaps you haven’t had a situation like that yet? One boring yet often very easy to understand example would be modeling somebodies role in school - a teacher with a subject or just a general pupil:

type alias Role =
  { is_teacher: Boolean
  , is_pupil: Boolean
  , subject: Maybe String
  }

I hope this seems fine at first? But it allows for impossible state being created:

{ is_teacher = False, is_pupil = False, subject = Just "Maths" }

The Maybe isn’t the root cause of it, but it’s just a “lazy” way to model the data - there is a custom type that models the situation perfectly:

type Role
  = Pupil
  | Teacher String

Now you ALWAYS have a subject for a teacher, because you cannot create a teacher without a string. Any you never have a subject for a pupil. Both of these impossible situations have been made impossible and are validated by the compiler. You also cannot have neither or both roles, but that’s not really result of wanting to fix the Maybe situation.

Hope that makes sense!

5 Likes