Using capitalized function names

[wildart]

How about to introduce capitalized function names: TRACE, WARN, DEBUG, INFO, ERROR, FATAL? This will solve problems with multiple dispatch warning on Base functions. There is already crippled err call, capitalized function names will help to avoid further interference with standard library.

[kmsquire]

Maybe. I think it might be better to try to integrate this into Base. Early on, @StefanKarpinski had expressed some interest in this, but I've never pushed it.

[StefanKarpinski]

I still think that integration with Base is the way to go. Basically, one should be able to write code with standard Julia where the output just gets printed normally and then load a logging package that plugs into that and changes how logging is handled (written to log files, syslogd, etc.). I.e. a single common interface that has a trivial default backend (printing to stderr), but which different backends can be swapped.

[wildart]

@StefanKarpinski, the question is how far design should go. Because I would prefer something similar to Log4j (with multiple loggers, format serializers & writers) to be able to output not only text but any data. However, I do not see it in scope of standard library. There going to be many implementations of loggers with different designs, the problem is how they going to interact with something permanently fixed in standard library. Look at definition of warn:

warn(msg...; kw...) = warn(STDERR, msg...; kw...)

It binds STDERR as output source. If we need something more flexible , let's say:

abstract Appender
type STDERRAppender <: Appender
 ...
end
warn(msg...; kw...) = warn(STDERRAppender, msg...; kw...)

but any abstraction of the output does not change the fact that there must be some configuration state inside the standard library that must be overwritten with a new setting.

Let's say we can solve the shared configuration issue with multiple loggers, each with its own configuration (we'll skip discussion about how this pool of loggers in stdlib will be managed). I still would like to get my own definition of warn at module level.

What if we could make the following:

• Make logging call dependent on some module constant that contains a logger configuration
• If this constant does not exists, provide default behavior.

Here is possible implementation of above (proof-of-concept).

This will solve dependency on the shared configuration state, but it is a bit awkward from design perspective - "special" logging constant object, really!?

And then to the issue topic - capitalized logging function names - there some functions that I would like to redefine for my own logging calls like trace or dump. There is no way to redefine their behavior at this point, especially error which behaves as throw. The logging function signature msg... overrides any priority. So clean start with capitalized names could be a nice idea after all.