request: automatic macro for reporting current function definition in error messages

[mjambon]

The request is about providing something like __FUNCTION__ in cpp but applicable to OCaml, whose purpose would be to provide better error messages by indicating the function or logical section of the program where an error occurs.

I suggested __CONTEXT__, an automatic macro that would contain the last contiguous sequence of non-empty, non-indented lines.

On 01/12/2012 01:15 AM, Francois Berenger wrote:
> Bonjour Martin,
> 
> Est-ce que ca serait possible d'avoir la macro
> __FUNCTION__ traitee par cppo?

Non, mais je note la requete.

> En C cette macro existe et est bien pratique
> pour logger des messages detailles (j'ai
> deja compris des bugs sans meme avoir a ouvrir le code source
> des fois grace a ca dans de gros softs en C),
> elle donne le nom de la fonction dans laquelle la macro est placee.
> 
> C'est vrai qu'un nom de fichier et un numero de ligne
> c'est pas si explicite que ca tant qu'on n'a pas ouvert
> le fichier source correspondant.

Il pourrait y avoir moyen de reporter les dernieres lignes non-indentees.

Par exemple:

let toto = 5

(* function for doing nothing *)
let nothing x =
  let f y = blah y in
  f x + 3

Une erreur sur "f x + 3" pourrait reporter les deux lignes suivantes pour indiquer le contexte:

(* function for doing nothing *)
let nothing x =

J'ai l'impression que git fait quelque chose comme ca pour afficher des diffs.

On pourrait mettre ca par exemple dans une macro __CONTEXT__

[UnixJunkie]

Hi,

As I am planning to use this macro for adding more info into log messages,
I think having a multi line output is not so nice.

Just the current function name would be useful and really reproduce the
behavior of the C preprocessor macro FUNCTION.

Regards,
F.

[mjambon]

There is no systematic and unambiguous "current function name" in OCaml. We have to find something useful that corresponds to the same usage pattern. In particular, what should we do with the following cases:

(* no function definition *)
let x = y + 1

(* is this a function definition? *)
let print = output_string stdout

(* which function to report? *)
let tail_from x l =
  let rec aux = function
      [] -> []
    | x' :: tl as l -> if x = x' then l else aux tl
  in
  aux l

[UnixJunkie]

I start to understand that implementing this is not trivial.
However, here are my naive answers:
(* no function definition *)
FUNCTION could be empty in such cases

(* is this a function definition? *)
yes, print is a function definition and not a function call

(* which function to report? *)
the inner most one

I hope experts at parsing OCaml source code will
give better answers.

[mjambon]

There is no way of distinguishing between cases (1) and (2) from the syntax only.

In case (3), the innermost function name is "aux" which like "x" is used all over the place. I don't think it would be very helpful to report just that.

[UnixJunkie]

mjambon said: "There is no way of distinguishing between cases (1) and (2) from the syntax only."
I agree. With types it would be possible.
Maybe it means that ocaml has a need need for a type-aware preprocessor.
I wonder if Haskell has one.

For case 3, I also agree, maybe the function name should be reported as:
[FILENAME].tail_from.aux

[mjambon]

Cppo was designed as an OCaml-compatible preprocessor strongly reminiscent of the C preprocessor. It does not know the grammar of OCaml, not even the list of reserved keywords.

Reporting the "indentation stack" may be worth exploring and doesn't need to be aware of the syntax of OCaml. Given the following code:

(* which function to report? *)
let tail_from x l =
  let z = 1 + 1 in
  let rec aux = function
      [] -> []
    | x' :: tl as l -> if x = x' then l else aux tl
  in
  aux l

An error on the "if-then-else" line could report the following:

let tail_from x l =
[...]
  let rec aux = function
[...]
    | x' :: tl as l -> if x = x' then l else aux tl

Note that I think that the goal of making an error message fit on a single line and the goal of making the same error message clearer are conflicting. If your log format requires one error message to fit a single line, just escape the LF characters and use another tool to read the log and display the error messages using as many lines are needed for readability.

[UnixJunkie]

I agree with the conflict on having one-line messages and their understandability.
Also, it is true that the example report you gave is already very useful to have
an idea of the context in which a crash occurs.