Re: [Caml-list] [ANN] Bisect_ppx 1.0.0 – Modernized code coverage for OCaml

[Anton Bachin <antronbachin@gmail.com>]

> Well I would have marked the "f x". My reasoning is simple, if f is
> executed, it should be green. And f is more important than try regarding
> coverage.

It certainly would be more readable, and we will keep this in mind.
However, I think we would delay addressing this for now, because there are
even more “bad” examples from the point of view of readability, that have
higher priority. For example, the first line of every case is typically not
marked (the pattern is marked instead):

http://rleonid.github.io/bisect_ppx/coverage/file0026.html#L41

So if the same try-expression was on the first line of a case, neither
the try nor the subexpression would end up marked by the current procedure.

While it would be nice to have a solution to this, short of marking every
subexpression, we are not sure what to do. There is some tradeoff between
marking every subexpression and trying to mark only “relevant" branching
points, and so far we have tried to stick to the latter option.

Perhaps it would be good to hear arguments for and against both options.

> Two remarks:
> 
> * If expressions are marked (which I suspected), then the HTML output
> should color at expression granularity level and not line granularity
> level. Therefore you would have only green or red and never orange[1]
> (which would be simpler and clearer);

The output is colored at the expression granularity level. The letters with
the bolder background are the real locations of each mark. Lines are then
colored according to whether they have visited marks, unvisited marks,
neither, or both.

What I think you are suggesting is that each line be subdivided into
subexpression spans, but I don’t think that will work – because an unvisited
expression might have a visited subexpression, for instance.

> * You could do some post-processing to look for such keywords as
> “then”, “else”, and “end” and color them accordingly. It might be more a
> hack than a clean approach, but I think it would make the output more
> readable.

Leonid briefly looked at doing this yesterday, and we will probably look
at it again, but we would expect it to be a bit of a kludge so we would
probably hesitate to implement it. It would make things more intuitively
readable, however, so we are keeping it in mind.


Regards,
Anton