Arvydas Silanskas <xxxxxx@gmail.com> writes:

> Debug level logs tend to be very verbose (frequent and/or big message
> output) and rarely enabled. As such, it's desirable for logs to not
> only be not printed when that level of logging isn't enabled, but for
> its message / data to not be even calculated or allocated
> (http://www.slf4j.org/faq.html#logging_performance). I don't have a
> strong opinion on how this should be implemented, but I think it's a
> point that is definitely worth thinking about in this srfi.

Thank you for the link to SLF4J. Their concerns are similar to the one
that this SRFI addresses, but as I understand it, they aim for something
different than this SRFI. They have a high-level logging system that can
direct its logs to one of several other logging systems.

As Marc mentioned, this SRFI is a middle-level logging system. I think
the feature you suggest is a good one to have in a logging system, but
more suitable for a high-level system, such as the one that Alex showed
us that Chibi has. SLF4J suggests that debug-level log calls can be
placed inside a conditional, which doesn't turn out very nice in Java,
but is nicely handled with Scheme macros.

I have been thinking in line with this famous statement from the intro
of RnRS:

  "Programming languages should be designed not by piling feature on top
  of feature, but by removing the weaknesses and restrictions that make
  additional features appear necessary."

The current draft defines one procedure, two parameters and one constant
for each of the standard eight (sys)log levels. This API is small, not
minimalistic, yet sufficient for the intended purpose. I think that
since we can implement the suggested feature in terms of this API and
syntax-rules macros, the lack of such a feature does not give us a
reason to say that there is a weakness or restriction in the current
draft.

Best regards,

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