Functor, Applicative, Monad implementations

[felixwiemuth]

This is an overview on the implementation status of the Functor, Applicative and Monad typeclasses.

Conventions for implementation, test and documentation

When implementing Applicative, I established some conventions (discussable of course):

• The actual implementation of a type class function is in the datatype's companion namespace, usually with the same name; the instance declaration redirects there.
  • When a type class's default implementation is used, there is still a function in the companion namespace which redirects to the default implementation.
• The implementation is documented at the companion namespace function, the description is as specific as possible to the datatype instead of as general as in the documentation of the type class. This makes the functions usable without knowing about type classes, and allows to look up the meaning of the implementation.
• If the instance declaration just redirects to the implementation in the companion namespace, we only test the function in the companion namespace.

Notes on some type classes

Applicative

• The type class has the function liftA2 as known from e.g. Haskell (plus liftA3, ..., liftA5)
  • The companion namespace in addition defines lift2, ..., lift5 though, as used in other places in the Flix standard library. These can also implement a more efficient version if possible, in which case liftAX would redirect to liftX.

Implementation

• :heavy_check_mark:: all functions implemented, tested and documented according to the above convention
• E: more efficient implementation needed
• T: tests incomplete

Datatype	Functor	Applicative	Monad
Option	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:
Result
List	:heavy_check_mark:	:heavy_check_mark: (E: ap, liftA2, T: liftX)	:heavy_check_mark:
Nel	:heavy_check_mark:	:x:	(:heavy_check_mark:)
Array	:heavy_check_mark:	:x:
MutList	:heavy_check_mark:	:x:

[magnus-madsen]

A general comment:

• Let us skip any mutable data structures, e.g. array, mut list etc. (My concern is that these are not lawful. We will deal with them later).
• Let us ensure that we have the most common instances, so e.g. Nel. (What about Result??)

[felixwiemuth]

Okay. Good point with Result, I'll check the instances for it when I come to Monad.

[mlutze]

Result/Validation may not be possible at the moment. See https://github.com/flix/flix/issues/1535

[stephentetley]

Is the pragmatic path to change the order of the type params for Validation and Result?

There will be quite a bit of code breakage - but if they are left longer there would be more breakage (if changing the param order remains the solution).

In Haskell fun deps and type families are the (competing) ways of programming on the "non-last" type params for some situations but dropping the last param of objects like Result is the way to make them kind -> so they can work with Functor, Applicative, Monad.