any logger in core?

[David House]

Hmm, I am surprised you want so many!

I claim there is a cost in allowing tons and tons of different log
levels. Firstly, it complicates the interface. Secondly, it leads to
different applications choosing different logging levels for
essentially the same errors. E.g. how do you choose whether some
particular failure is an error, or a fatal? Isn't it likely that
someone else will make a different choice? There are lines that you
can draw, but it's a big grey area. Having fewer choices means that
everyone's programs are more consistent with respect to each other.

Putting it another way: three logging levels should be enough for anyone! :)

On Tue, Nov 13, 2012 at 8:02 AM, Francois Berenger
<francois.berenger.working at gmail.com> wrote:
> The choice in log levels is a little scarce.
>
> Currently:
> raw (I don't know it's level, I guess it's always printed but I may be
> wrong)
> then, ordered by my intuitive notion of log priority:
> debug < info < error
>
> I'm used to:
> debug < info < warn < error < fatal
>
> So, I miss the warning and fatal log levels.
> But, that's just based on my experience.
>
> Regards,
> F.
>
>
> On Thursday, November 8, 2012 7:13:25 PM UTC+9, David House wrote:
>>
>> On Thu, Nov 8, 2012 at 3:48 AM, Francois
>> <francois.b... at gmail.com> wrote:
>> > I don't know where to find never_returns.
>>
>> It's there if you open Core.Std.
>>
>> > But the following did work (and never stop):
>>
>> You need to explicitly shut down async using the shutdown function in
>> Async.Std.
>>
>> > I'm affraid of open directives, I try to keep my code _very_ explicit
>> > about what it is doing and which function from which module is used
>> > (maybe because of past overexposure to some C++ code).
>>
>> I think that's exactly the right approach -- I often find myself
>> making similar comments when doing code review at work. Things are
>> much easier to follow if opens are reduced, or made more local, and
>> more explicit.
>>
>> That being said, I do allow myself the luxury of opening Core.Std and
>> Async.Std in most of my modules that use core / async. I find this to
>> strike a good balance between concision and explicitness.
>>
>> One of the reasons is that there are very few *values* brought into
>> scope by opening Core.Std and Async.Std. This conversation has contain
>> disproportionally many: never_returns, shutdown, etc. -- an unlucky
>> coincidence! But nearly everything is squirreled away inside a module,
>> which helps a lot. (In other words, our "Pervasives" is much smaller
>> than the ocaml standard library's.)