On Tuesday, November 13, 2012 5:43:01 PM UTC+9, David House wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hmm, I am surprised you want so many!

<br>

<br>I claim there is a cost in allowing tons and tons of different log

<br>levels. Firstly, it complicates the interface. Secondly, it leads to

<br>different applications choosing different logging levels for

<br>essentially the same errors. E.g. how do you choose whether some

<br>particular failure is an error, or a fatal?</blockquote><div><br>After a fatal error, the program cannot continue anymore.<br>Think about a "fatal injury".<br>I see a grey zone between warn and error, but I think<br>programmers are usually smart and can be trusted.<br><br></div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> Isn't it likely that

<br>someone else will make a different choice? There are lines that you

<br>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.

<br></blockquote><div><br>I agree it's a grey zone.<br>But the current choice is drastic.<br> </div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">

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

<br>

<br>On Tue, Nov 13, 2012 at 8:02 AM, Francois Berenger

<br><<a href="javascript:" target="_blank" gdf-obfuscated-mailto="V1bEAMLACLQJ">francois.ber...@<wbr>gmail.com</a>> wrote:

> The choice in log levels is a little scarce.

<br>>

<br>> Currently:

<br>> raw (I don't know it's level, I guess it's always printed but I may be

<br>> wrong)

<br>> then, ordered by my intuitive notion of log priority:

<br>> debug < info < error

<br>>

<br>> I'm used to:

<br>> debug < info < warn < error < fatal

<br>>

> So, I miss the warning and fatal log levels.

> But, that's just based on my experience.

<br>>

<br>> Regards,

<br>> F.

<br>>

<br>>

<br>> On Thursday, November 8, 2012 7:13:25 PM UTC+9, David House wrote:

<br>>>

<br>>> On Thu, Nov 8, 2012 at 3:48 AM, Francois

<br>>> <<a>francois.b...@gmail.com</a>> wrote:

>> > I don't know where to find never_returns.

<br>>>

>> It's there if you open Core.Std.

<br>>>

<br>>> > But the following did work (and never stop):

<br>>>

<br>>> You need to explicitly shut down async using the shutdown function in

<br>>> Async.Std.

<br>>>

<br>>> > I'm affraid of open directives, I try to keep my code _very_ explicit

<br>>> > about what it is doing and which function from which module is used

>> > (maybe because of past overexposure to some C++ code).

<br>>>

<br>>> I think that's exactly the right approach -- I often find myself

<br>>> making similar comments when doing code review at work. Things are

<br>>> much easier to follow if opens are reduced, or made more local, and

<br>>> more explicit.

<br>>>

<br>>> That being said, I do allow myself the luxury of opening Core.Std and

<br>>> Async.Std in most of my modules that use core / async. I find this to

>> strike a good balance between concision and explicitness.

<br>>>

<br>>> One of the reasons is that there are very few *values* brought into

<br>>> scope by opening Core.Std and Async.Std. This conversation has contain

<br>>> disproportionally many: never_returns, shutdown, etc. -- an unlucky

<br>>> coincidence! But nearly everything is squirreled away inside a module,

<br>>> which helps a lot. (In other words, our "Pervasives" is much smaller

<br>>> than the ocaml standard library's.)

<br></blockquote>