22 | export
29 | ||| Chaining computation
30 | ||| Different from ordinary `Either` in that both variables are of the same type
31 | export
36 | ||| Corresponds to the Applicative instance in `Prelude.Types`
37 | ||| It behaves like a cartesian product, but compared to `Prelude.Types`
38 | ||| applicative this is layout-aware
39 | export
44 | export
48 | {--
49 | It is usually said that List has two applicative structures: one defined above,
50 | and another one defined by `zipList` (Section 3 of
51 | https://www.staff.city.ac.uk/~ross/papers/Constructors.pdf). However, such
52 | a definition relies on the laziness of the underlying programming language
53 | and implicitly recast the type not to `List` but `CoList` (sometimes called
54 | `LazyList`), i.e. a list with potentially infinite number of elements. This permits defining `pure` and showing that applicative laws hold. However, since Idris is a strict language, List is not equal to CoList, and we cannot lawfully
55 | make `List` an applicative functor. More precisely, the following is not a valid applicative instance, because unital laws do not hold:
57 | Applicative List where
58 | pure a = [a]
59 | fs <*> xs = uncurry ($) <$> listZip fs xs
60 | --}
63 | ||| Covers pairs, vectors, streams, grids, among others
64 | ||| For vectors produces a `zip` operation
65 | export
76 | ||| When a container `c` is Naperian, then `c >< c` is isomorphic to `c >@ c`
77 | ||| Meaning this interface follows directly
78 | ||| Vectors also form a *graded* monad, which isn't implemented here
79 | export
84 | ||| Tensor preserves TensorMonoid/Applicative
94 | ||| experiment, does this work?
137 | -- needs to be checked if this is right... some previous related code at
138 | -- git show adf4ad5:src/Data/Container/Applicative/Instances.idr
183 | export
188 | export
193 | -- Note, there is no TensorMonoid/Applicative instance for BinTreeNode
194 | -- There exists one for infinite trees, but not finite ones