[vilunov]

> I wonder if this will wind up being a category of problems and the solution is a separate "system" set of effects (effectively `({user}, {system})`) or if this one-off extension is all that will be needed.

It already is, kinda. In my practice very often you have global singleton values that are either defined as static variables, or passed as arguments to nearly all functions in a module. Since implicit presence of `Debug` effect is already a compilation parameter, it could be generalized to support any sets of implicit effects. Thus you might design a module that has implicit Logger and Database effects in all its functions.

[yccs27]

> Thus you might design a module that has implicit Logger and Database effects in all its functions.

Logging does seem like a very similar case to debugging, only that you expect to leave it on in production. On the other hand an implicit Database effect kind of defeat the point of an effect system.

I think the key is that Debug and Logger effects don't really affect the rest of the code - if you remove all debug/log statements, the only thing that changes is the debug/log output (and slightly faster execution probably).

[saghm]

> Logging does seem like a very similar case to debugging, only that you expect to leave it on in production

In a lot of logging systems, debug is one of the common levels of logging. I'm not even convinced that the term "debug" is unambiguous to clearly refer to something that's not a subset logging. Presumably the difference is intended to mean things printed that are unconditionally going to stdout rather than into some system that might change the output location and filter/annotate things, but I have to imagine that it might just make more sense not to have separate models for them at all

[yccs27]

I was referring to the specific Debug effect described in the post, which only works in debugging builds. This means that the production build cannot have unexpected output from a function with no declared effect.

[saghm]

I understand. My point was that if you did want to extend further to have an effect for logging, it seems like having fully separate abstractions for them rather than finding a way to express them both as part of the same abstraction would make sense.

[epolanski]

Singleton pattern isn't really used in functional-effect systems, dependency injection is generally used instead.