improve docs

This commit is contained in:
Marco Perone 2023-04-06 10:31:31 +02:00 committed by Marco Perone
parent 78157a2296
commit 393340a1d8
3 changed files with 3 additions and 3 deletions

View File

@ -95,7 +95,7 @@ which allows combining multiple machines with the same output but different inpu
## [`Arrow`](https://hackage.haskell.org/package/base-4.17.0.0/docs/Control-Arrow.html#t:Arrow)
The `Arrow p` class describes computations similarly to what `(Category p, Strong p)` do. The main difference is that is also requires that every function `a -> b` could be interpreted as `p a b`.
The `Arrow p` class describes computations similarly to what `(Category p, Strong p)` do. The main difference is that is also requires that every function `a -> b` could be interpreted as `p a b`, while `p` does not need to be a `Profunctor`.
Its basic operations are

View File

@ -284,7 +284,7 @@ stateDiagram-v2
SecondVertex --> ThirdVertex
```
Since we need the topology information at the type level, we wrap the two type definitions in
Since we need the topology information at the type level, we wrap those two declarations in
```haskell
$( singletons

View File

@ -18,7 +18,7 @@ For example, this is the graph produced for the [`LockDoor`](/src/Crem/Example/L
Rendering the state space for big machines could be quite uninformative, because it could easily get quite big.
A possibly more useful representation is provided by the flow representation which can be generated using the `renderFlow` function from the [`RenderFlow`](/src/Crem/Render/RenderFlow.hs) module.
A possibly more useful representation is provided by the flow representation (i.e. a graph showing the state space of each `Basic` machine and how they were composed) which can be generated using the `renderFlow` function from the [`RenderFlow`](/src/Crem/Render/RenderFlow.hs) module.
To be called, it requires us to annotate every leaf of our tree of machines with a label, which will be used in the drawing.