From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 2514C7EEFD for ; Tue, 2 Jun 2015 10:22:02 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=pra; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=mailfrom; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mailhost.math.nagoya-u.ac.jp) identity=helo; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="postmaster@mailhost.math.nagoya-u.ac.jp"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B3AwDQZm1VlwWCBoVbhEK+aodRAoFuEgEBAQEBAQERAQEBAQEIFgdPQQWDXQEBBDoGAwE1AQEOCxgcElcGiD+0A4VaAppjhFMBAQEBAQEBAwEBAQEBAQEBEwEGi0OEUzMHgxeBFotca5FklziEKmCCRwEBAQ X-IPAS-Result: A0B3AwDQZm1VlwWCBoVbhEK+aodRAoFuEgEBAQEBAQERAQEBAQEIFgdPQQWDXQEBBDoGAwE1AQEOCxgcElcGiD+0A4VaAppjhFMBAQEBAQEBAwEBAQEBAQEBEwEGi0OEUzMHgxeBFotca5FklziEKmCCRwEBAQ X-IronPort-AV: E=Sophos;i="5.13,538,1427752800"; d="scan'208";a="161398858" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail2-smtp-roc.national.inria.fr with ESMTP; 02 Jun 2015 10:21:59 +0200 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 9F4FF6454; Tue, 2 Jun 2015 17:21:56 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (rabbit-172 [172.16.254.254]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id C972D24FF; Tue, 2 Jun 2015 17:21:55 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=math.nagoya-u.ac.jp; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=alpha; bh=5zkCEnGP1JTYnef9Oh3HkGouZh8=; b=1qc10zz8N+BNpz8/E8VXLemBb46G 29FaANm+Sr4Bb+eD9mCbmAr2ve94BpNBHxSFacTV8gGh9AK68wUA0g+/Vvleu9dq NLglvk6WHcw7i03/OirR0MxcHGZU1PfOVzSEM1KjR1QrHISjQ72JlLfNp5tejjTh bW1Te9kzBtlvBNw= DomainKey-Signature: a=rsa-sha1; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=aT/ybwrmtN9nZCC+BgKju1LMKOWPLhzSAE+eZR6NpD5ut/L/f1ePYO4YaQ+kj3N6KItqqIJFk63wo1jbmWRKgwsedm6LGkJnPsImX4XN3LEaA6DoU0aQ5Uj/YkMlnpwAE6MxEbydTEUMaasnfiMnRgVVCH0ESsid3P1+wV7D7fY=; c=nofws; d=math.nagoya-u.ac.jp; q=dns; s=alpha Received: from tet.garrigue.jp (58x158x128x157.ap58.ftth.ucom.ne.jp [58.158.128.157]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id AB1C86E58; Tue, 2 Jun 2015 17:21:30 +0900 (JST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jacques Garrigue In-Reply-To: <556D64EC.7060800@inria.fr> Date: Tue, 2 Jun 2015 17:21:54 +0900 Cc: OCaML List Mailing Content-Transfer-Encoding: quoted-printable Message-Id: <122414E6-2549-4386-8106-2D18ECB8D787@math.nagoya-u.ac.jp> References: <556C4512.2050002@free.fr> <556C89F3.3000206@free.fr> <556D64EC.7060800@inria.fr> To: Francois Berenger X-Mailer: Apple Mail (2.2098) Subject: Re: [Caml-list] getting the name of a function from its body On 2015/06/02 17:10, Francois Berenger wrote: >=20 > 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 : >>=20 >> let f x =3D x+1 >> let f list =3D List.map f list >>=20 >> 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). >>=20 >> In OCaml, it is probably better to use the pair (__FILE__, __LINE__) >> to tell the dev where to search for the problem. >=20 > Then, the triplet (__FILE__, __LINE__, __FUNCTION__) is unique in OCaml. >=20 > 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. >=20 > 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 enclosin= g function name in the compiler, which is not done at all currently. Also, this feature would require some kind of specification: I suppose by f= unction you mean the enclosing toplevel let, but we also have the case of c= lasses, where the occurence might be in the initialization part or inside a= method, and of course cases where the definition has no name (toplevel exp= ression 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 co= mplex than __FILE__ and __LINE__, which come directly from the parser and a= re readily available in the syntax tree. Jacques=