Lassi Kortela <xxxxxx@lassi.io> writes:

> SRFI 215 wisely constructs log entries from arbitrary key-value pairs.
> The severity level is the only exception to this rule.

Severity /and message/ are the only ones that aren't arbitrary, and they
are the minimum required to have a valid log entry.

> My intuition says it may not be that simple to work things out in a
> big system such that severity is the only by which you'd like to
> filter logs at compile time. And it may not be simple to have a
> universal severity scale that is respected by every part of the
> program (including third-party libraries).

But there is nothing special in SRFI-215 for filtering on severities, or
anything else for that matter. The log callback can do filtering, but
that's just because you can set it to an arbitrary procedure.

The previous discussion was about filtering that happens in a high-level
logging system, which is at least one step before logs reach SRFI-215.
Such systems do usually have special objects called "loggers" that can
filter on severities, and applications commonly create one logger per
module or subsystem. This is orthogonal to SRFI-215.

> If the main point of severity is to have a sliding scale on which
> logging verbosity can be controlled at runtime, wouldn't it be equally
> simple and more future-proof to let programmers add mixins to the log
> callback to filter which entries are logged?

The point of the severity field is not *quite* to control logging
verbosity. It has to do with the nature of the message. Someone writing
a log message should have a feel for how serious a message is.

(define EMERGENCY 0)                ; system is unusable
(define ALERT 1)                    ; action must be taken immediately
(define CRITICAL 2)                 ; critical conditions
(define ERROR 3)                    ; error conditions
(define WARNING 4)                  ; warning conditions
(define NOTICE 5)                   ; normal but significant condition
(define INFO 6)                     ; informational messages
(define DEBUG 7)                    ; debug-level messages

These are not just for filtering. Have you seen what happens with
EMERGENCY on a Unix system? Try these commands on a Linux system (with
nobody else logged in, preferably):

$ logger -p 7 "Foo bar quux"
$ logger -p 0 "The coffee maker is kaput"

The first command goes away quietly to sit in some corner on your system
(you can probably find it in journalctl -f). The second one is broadcast
to all users on all terminals. The behavior is distinctly different for
an EMERGENCY message, because the severity means something that has
consequences in the real world, it's not just for filtering logs.

As for your suggestion to allow mixins to the log callback, this is
already possible. The current log callback is a parameter, so the user
can retreive it and wrap it around another procedure, e.g. one that
filters before calling the previous callback.

> If the point is to enable compile-time macros that can leave verbose
> messages off the build product altogether, could identifiers be used
> for that purpose? It would enable finer-grained control than one
> global log level.

I did not catch the detailed meaning of this brief description, but I
think it goes back to the discussion of high-level logging systems.
SRFI-215 does not limit how high-level logging systems create their
loggers, so I think there is no problem here.

SRFI-215 is just a central point for log systems to meet and exchange
messages. (This is also why I felt it was extra appropriate to make it a
SRFI; the idea doesn't work as well if there are multiple such exchanges
in the same program. It would be like having multiple definitions of
current-input-port and current-output-port).

--
Göran Weinholt   | https://weinholt.se/
Debian Developer | 73 de SA6CJK