Add record types concept and associated exercise

[ceddlyburge]

Add records concept and associated exercise

The configlet linter is still failing, but this has been fixed in main, so will be fixed when this is merged.

[mpizenberg]

Thanks for this! It's great since I'll need it as a dependency for the exercise I'm making for Maybe. I've reviewed and made changes to the about.md docs. The main changes:

• Cosmetics:
  • to follow exercism guideline about markdown documents I've put one sentence per line.
  • for elm code blocks, I've aligned everything to the left and tried to make code consistent between each block
  • for results in elm code blocks I'm using --> since it's the syntax expected by elm-verify-examples which is often used in packages to make sure examples in the docs are not stale.
• Content:
  • I've added segmented each part into a subsection because it seemed to be a lot of content
  • I added a section about extensible records
  • other small rephrasing

Let me know what you think of all this.

[ceddlyburge]

Thanks Matthieu, those changes look good. I should finish the rest of the PR by the weekend I think.

[mpizenberg]

Hi @ceddlyburge . I've finally had some time to review again your changes. I've rebased this on a newer main commit to avoid merge conflict with list concept. I was surprised that you didn't go for TV shows for the exercise but I like the bandwagoner theme too! I have some questions and remarks about the exercise, here they are.

---

Are you using only the record constructors in the examples to not disclose the structure too much, or for example brevity? It is usually preferable to use the curly braces syntax to define them because the constructors are dependent on order, thus potential sources of hard-to-find bugs. So I'm not sure if it is worth trying to have shorter code examples if it gives the wrong habits to students. What do you think?

For the replaceCoach function, I'd reverse the order of arguments. It's generally good to end arguments with the same type that is transformed since it improves readabily in pipes, so Coach -> Team -> Team.

Do you think the isSameTeam task is worth it? Equality in Elm works the same everywhere, and there is no concept of referential equality (except for Html lazy but that's a very particular edge case), and there is only one operator == so it's not like they could get it wrong.
I'm wondering if the small paragraph in the introduction is enough.

I feel the exercise is missing a "constructor" function. By that I mean a function that would make the student write the { field = ..., ... } entirely. I feel like a good function to do that would be to provide the arguments in the wrong order, compared to the auto-generated constructor. Something like this where Stats and Coach are reversed, preventing the student to use the Team constructor.

createTeam : String -> Stats -> Coach -> Team
createTeam name stats coach =

And at the beginning, in the instructions to define the model, we should add "with the following fields, in the following order". Then the first tests should check that the order is respected. And Same for the other type aliases.

test "Coach type alias is correctly defined" <|
    \_ ->
        Coach "Steve Kerr" True
            |> Expect.equal
                { name = "Steve Kerr"
                , formerPlayer = True
                }

Finally, regarding the rootForTeam function, if we want to make students use the extensible record syntax, we should add a test with a record that isn't a Team.

[ceddlyburge]

I was surprised that you didn't go for TV shows for the exercise but I like the bandwagoner theme too! I have some questions and remarks about the exercise, here they are.

I have been trying to pick the low hanging fruit, and copy exercises from other languages. I didn't come across the TV shows one when I was looking, which track is this on (I looked at quite a few function type tracks, such as F#, Scala, Haskell, Clojure, Rust etc)

[ceddlyburge]

Are you using only the record constructors in the examples to not disclose the structure too much, or for example brevity? It is usually preferable to use the curly braces syntax to define them because the constructors are dependent on order, thus potential sources of hard-to-find bugs. So I'm not sure if it is worth trying to have shorter code examples if it gives the wrong habits to students. What do you think?

This is a fair point, although I often use the constructors, partly because it communicates the type you are creating. It's true that if you have multiple properties of the same type it would be easy to mix them up though. I'll commit some changes.

[ceddlyburge]

For the replaceCoach function, I'd reverse the order of arguments. It's generally good to end arguments with the same type that is transformed since it improves readabily in pipes, so Coach -> Team -> Team.

Fair point, I'll commit this change now

[ceddlyburge]

Do you think the isSameTeam task is worth it? Equality in Elm works the same everywhere, and there is no concept of referential equality (except for Html lazy but that's a very particular edge case), and there is only one operator == so it's not like they could get it wrong.
I'm wondering if the small paragraph in the introduction is enough.

Yep, fair enough, I'll remove this

[ceddlyburge]

And at the beginning, in the instructions to define the model, we should add "with the following fields, in the following order". Then the first tests should check that the order is respected. And Same for the other type aliases.

Good point, I've done this.

[ceddlyburge]

I feel the exercise is missing a "constructor" function. By that I mean a function that would make the student write the { field = ..., ... } entirely. I feel like a good function to do that would be to provide the arguments in the wrong order, compared to the auto-generated constructor. Something like this where Stats and Coach are reversed, preventing the student to use the Team constructor.
Ok, I've added that

[ceddlyburge]

Finally, regarding the rootForTeam function, if we want to make students use the extensible record syntax, we should add a test with a record that isn't a Team.
Good point, I've added a test

[ceddlyburge]

I think that is all the feedback for this PR addressed now, can you give it another look? Thanks, Cedd

[mpizenberg]

Looks great to me! one more concept ;)