PTV/book-monads
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

solution to prioritised errors

Browse Source
This commit is contained in:
AF 2023-05-21 23:55:07 +00:00
parent f1a17032d2
commit 5848712189
1 changed files with 4 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
src/ch04/s05-fail.md
View File

@ -6,11 +6,7 @@
* Have `Fail` as a separate trait with the error and the class as associated types. * Have `Fail` as a separate trait with the error and the class as associated types.
* `OverloadClass` to mix-in additional `Fail`. * `OverloadClass` to mix-in additional `Fail`.
## Lack of support for strict ordering of errors ## ~~Lack of support for strict ordering of errors~~
* Current (possible) implementations of having one error or another either allow short-circuiting * ~~Current (possible) implementations of having one error or another either allow short-circuiting on only one of them, or give them both the same priority. **Right now this model is considered the main one**, i.e. this restriction may get stabilised and standardised at some point.~~
on only one of them, or give them both the same priority. * ~~More complex behaviours are expected to require a more complex execution model, with states taking messages from other states and optionally dropping their own execution, if their result\['s error\] is guaranteed to be "less severe" than the error it receives.~~
**Right now this model is considered the main one**, * Solution: `Fallible::W<E0>::F<Fallible::W<E1>::A>`
i.e. this restriction may get stabilised and standardised at some point.
* More complex behaviours are expected to require a more complex execution model, with states
taking messages from other states and optionally dropping their own execution, if their
result\['s error\] is guaranteed to be "less severe" than the error it receives.