Matthias Benkort

Could you elaborate a bit :) ? What feels wrong to you? The substitution? The code simplification? The condition evaluation?

Okay. I think with @emily-li 's remark, I now understand @davidsells' one. To be clear here, this isn't about _refactoring_ equivalent part of the code with another. Seemingly, `team` isn't...

Agreed that this deserve a paragraph in the book somewhere in the introduction or preface. A lot of functions and data structures presented actually holds under the assumption that they're...

There's indeed an issue with the combination of those functions. In the end, it'd make more sense to rely on a `find` intermediate function with an appropriate signature. ```js //...

@deleite this doesn't quite work, if you look at the type signature, the end result should be a `Either e a`. There's little we know about `e` but we can...

I like this `parseIntBase10` helper which leaves the ambiguity out. I am considering adding this to the appendix and update references of it in the code :+1:

Nice catch. What about using: https://github.com/MostlyAdequate/mostly-adequate-guide/blob/master/appendix_a.md#always ?

I am not sure to follow you on that one. We have: ```hs always :: a -> b -> a getValue :: Selector -> Task Error (Maybe String) getValue("#comment") ::...

Hmmm. That is incorrect. The type for `always(getValue("#comment"))()` is actually `Task Error (Maybe String)`. Having `Unit` (a.k.a `()`) in a type signature just means that it only accepts one value...

Hi, great to hear that :) And... hmmm... I guess that you're right (and thanks for pointing that out!). Let's consider the object target as the first argument of a...