Re: [Caml-list] getting the name of a function from its body

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

On 2015/06/02 17:10, Francois Berenger wrote:
> 
> On 06/01/2015 11:57 PM, Fabrice Le Fessant wrote:
>> The main reason for the absence of __FUNCTION__ is probably that it
>> does not really make sense : you might have several functions with the
>> same name within the same module :
>> 
>> let f x = x+1
>> let f list = List.map f list
>> 
>> It makes sense in C, because you can only define a symbol once in a
>> file, so the pair (__FILE__, __FUNCTION__) is uniq (and if the
>> function is not static, it is probably even uniq within the
>> executable).
>> 
>> In OCaml, it is probably better to use the pair (__FILE__, __LINE__)
>> to tell the dev where to search for the problem.
> 
> Then, the triplet (__FILE__, __LINE__, __FUNCTION__) is unique in OCaml.
> 
> The problem I saw a long time ago while working with people who were not programmers (but still scientits)
> is that they have more chance to fix an error in one of their input
> file when given the function name than when not.
> 
> And since I created and maintain a logging library in OCaml, I was (and I am still) interested into making log messages as useful as possible to end users.


You make a good point here.
The subtlety however is that it would require keeping track of the enclosing function name in the compiler, which is not done at all currently.
Also, this feature would require some kind of specification: I suppose by function you mean the enclosing toplevel let, but we also have the case of classes, where the occurence might be in the initialization part or inside a method, and of course cases where the definition has no name (toplevel expression of pattern-matching with several components).
Also should we do something special for submodules? functors?
Anything may be better than nothing, but this ends up being clearly more complex than __FILE__ and __LINE__, which come directly from the parser and are readily available in the syntax tree.

Jacques