Documentation tweaks and fixes

This commit is contained in:
Nathan McCarty 2025-01-23 00:17:19 -05:00
parent 9489721e29
commit 407149dd4a
4 changed files with 29 additions and 13 deletions

View file

@ -26,6 +26,11 @@ solution.
Extend the functionality of the effects included in the
[eff](https://github.com/stefan-hoeck/idris2-eff/) library
- [Util.Digits](src/Util/Digits.md)
Provide views that enable recursively pattern matching numbers as lists of
digits, in both ascending and descending order of significance.
# Index of years and days
- 2015

View file

@ -181,8 +181,8 @@ failures doing so.
## Handling the arguments and finding the input
Handle the verbosity flag, if it is set, hook our logger up to stderr, otherwise
blackhole the logs. Afterwards, use `logHandler` to introduce the logging
`Writer` into the effects list.
blackhole the logs. Afterwards, use `logHandler` to introduce the `Logger` into
the effects list.
```idris
-- If the verbose flag is set, hook up the logging writer to stderr
@ -259,8 +259,8 @@ a `SolveError`, then print out the result, then return, closing out the program.
### Lower logging into the IO component of the effect
This function uses the provided `String -> IO ()` to remove the `Writer` from
the effects list by translating `tell` calls to IO actions within the effect.
Makes use of `Logger`'s `handleLoggerIO` function to "lower" logging actions
into `IO` within the effect.
```idris
-- Lowers logging into IO within the effect using the given IO function

View file

@ -28,9 +28,9 @@ function to have a single source of truth for this. The `err` type can be any
type with a `Show` implementation, but that constraint will be tacked on in the
next step.
A `Writer` effect is provided for logging, and a `Reader` effect is provided to
pass in the input, just to make the top level API a little bit cleaner. `IO` is
also provided, even though the part solutions themselves shouldn't really be
The `Logger` effect is provided for logging, and a `Reader` effect is provided
to pass in the input, just to make the top level API a little bit cleaner. `IO`
is also provided, even though the part solutions themselves shouldn't really be
doing any IO, this may come in handy if a part needs `IO` for performance
reasons.

View file

@ -22,9 +22,18 @@ import System.File
Basic enumeration describing log levels, we define some (hidden) utility
functions for working with these.
The `Other n` log level is restricted to `n` greater than 4, to prevent
ambiguity between custom log levels and predefined log levels.
```idris
public export
data Level = Err | Warn | Info | Debug | Trace | Other Nat
data Level : Type where
Err : Level
Warn : Level
Info : Level
Debug : Level
Trace : Level
Other : (n : Nat) -> {auto _ : n `GT` 4} -> Level
```
<!-- idris
@ -44,7 +53,7 @@ natToLevel 1 = Warn
natToLevel 2 = Info
natToLevel 3 = Debug
natToLevel 4 = Trace
natToLevel k = Other k
natToLevel (S (S (S (S (S k))))) = Other (5 + k)
export
Eq Level where
@ -130,10 +139,8 @@ handleLoggerIO max_level x =
else pure . ignore $ x
```
Use the `WriterL "log" String` effect like a logging library. We'll provide a
few "log levels" as verbs for the effect, but no filtering is done, when logging
is enabled, all logs are always displayed, however the log level is indicated
with a colored tag.
Provide a family of effectful actions that emit log messages at the different
log levels.
```idris
export
@ -155,6 +162,10 @@ debug x = send $ Log Debug x
export
trace : Has Logger fs => Lazy String -> Eff fs ()
trace x = send $ Log Trace x
export
logAt : Has Logger fs => Level -> Lazy String -> Eff fs ()
logAt level x = send $ Log level x
```
## Choose