teach Daml module design with typeclasses

[S11001001]

In our current approach to teaching Daml, we necessarily teach use of existing typeclasses, as we define many as part of the Daml standard library and triggers library, but not definition of one's own typeclasses as part of the design of users' own Daml modules.

There are reasons to teach typeclass design, and to continue to avoid it.

@leonidr-da questioned the presence of newtype in the language.

To which I responded that GND is a huge benefit. Someone who wants to use it will naturally check whether newtypes work, and they do. At the same time, deriving typeclass instances is hard to motivate without explaining why you would want typeclass instances in the first place, so that's a heavy burden to put on people learning Daml. "Justifying the availability of newtype" isn't quite a good enough reason to teach typeclass design.

@leonidr-da is in favor, as typeclasses are "one of the latent selling points of Daml. We are building DSLs all the time".

@asarpeshkar-da agrees, as typeclasses are already impossible to avoid as a Daml developer, so shying away from them eventually becomes an impediment to learning. They "are an elegant and powerful abstraction in their own right, so why not tell users about them?"

[S11001001]

An experiment in this direction on the forum.

[garyverhaegen-da]

My experience learning Haskell has been that typeclasses are not harder to understand than Java interfaces. They just have that neat trick where you can still add the interface to a type after the fact, and that's great, but doesn't really increase the cognitive complexity.

Based on that, I'm in favour.