Add a type parameter! One 'simple' design change, a panoply of outcomes

Compose Conference: Add a type parameter! One 'simple' design change, a panoply of outcomes

Many of the "classical" design patterns from the GoF don't really apply cleanly to Haskell because so many of them do things like reimplement partial application by storing some arguments in an object, or implement objects with a single "invoke" method to imitate functions as first-class values. Built-in language features render such patterns unnecessary. (Exception: the Interpreter Pattern, which Steve Yegge calls "the only GoF pattern that can help code get smaller", and the subject of a great Scala talk by Rúnar Bjarnason). The "just use functions" advice is simple and true, but probably not helpful until you've already internalised it. Many of your software engineering instincts still…

You will probably have one big state and a function **PlayerInput -> GameState -> GameState**. The trick is how to decompose that function into manageable components that only know about the parts of the global state they actually need. Updating deeply nested records is a bit of a pain in Haskell. There's a solution for that called "lenses" (composable getters/setters) but unfortunately they are a bit above newbie level. I would try to get by without lenses at first. At the very least, you'll gain insight into their motivation. Remember that records can have type parameters and allow polymorphic update (you can change the type of a parameterized record using an update). This can be useful…

There was another recent post about how to deal with record boilerplate. It seems to be a frequent problem. > The reason I do that is mainly because I don't want to expose details of the server to the client Can the "internal bits" be abstracted away using a type parameter, that would be mapped to () when generating the JSON? Something like what's explained there: link to this video Or perhaps you could go the other way: make the "internal bits" a separate datatype that would contain the "public bits" record as a field.

> It shall report all type errors in the program, not stopping at the first error How about using a Validation Monad? There are several implementations with different tradeoffs, but the idea is always the same: a variant of Either with accumulates all the errors instead of stopping at the first one. > It shall only report error where it is first encountered, not propagating it Do you have an example expression in which you are afraid that the error might propagate? If you declare a variable of type `int` and then use twice it as if it had type `bool`, do you want one or two errors? What if it's called a third time as a `string`? > It shall add type info to each node of the AST, which may…