From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id DBC4BBB84 for ; Wed, 24 Sep 2008 09:50:44 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIBALyO2UjRVcbjlGdsb2JhbACSZz4BAQEBCQkMBxEDmyFrh2wBAg X-IronPort-AV: E=Sophos;i="4.33,299,1220220000"; d="scan'208";a="17680708" Received: from rv-out-0506.google.com ([209.85.198.227]) by mail1-smtp-roc.national.inria.fr with ESMTP; 24 Sep 2008 09:50:41 +0200 Received: by rv-out-0506.google.com with SMTP id f6so2314510rvb.3 for ; Wed, 24 Sep 2008 00:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SujHFwzpjm2qY+XyI6/wMOWyDAO16IrkXxxWsKJ2qRk=; b=g3HNtMhjO8hhN3gbww1Zu/0fYqzF69sLKLVufbjZmyuOOKkOIy5wLyipbKuFc/9XGQ 74bBrXj+zVy5k9kVpw19rbU+B7sNirGRYZHyGIo7rOmLdc2st3Q7SR6jvzbE7vxGze7E x2yyjHIKd0Q74t4aH1r1yDpD1/rmByddz/wbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=G0QYGQmssb4vhsnxjls2sYS1GPIn01wwCvJBEL7H7d7uZfqIVJxWShbR+tRtx8ft4G ToM6FYyEw5NLIC7wW1+wGla5WlBI9s5J5P6ub8yfhMgCTGixV4ogK7sQ9tDYKRFnzNpz ujPQgwJQ6kTlaNLbbi0Rv4RiUsu2W7Ks3JK6M= Received: by 10.140.172.20 with SMTP id u20mr2370964rve.16.1222242640625; Wed, 24 Sep 2008 00:50:40 -0700 (PDT) Received: by 10.141.123.21 with HTTP; Wed, 24 Sep 2008 00:50:40 -0700 (PDT) Message-ID: Date: Wed, 24 Sep 2008 00:50:40 -0700 From: "Nathaniel Gray" To: "Maxence Guesdon" Subject: Re: [Caml-list] Extending .annot files Cc: caml-list@yquem.inria.fr In-Reply-To: <20080922080824.38b9cc59@alcazar.inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080922080824.38b9cc59@alcazar.inria.fr> X-Spam: no; 0.00; maxence:01 guesdon:01 maxence:01 guesdon:01 compiler:01 foo:01 foo:01 cmo:01 cheers:01 wrote:01 wrote:01 caml-list:01 functions:01 inferred:02 referenced:02 On Sun, Sep 21, 2008 at 11:08 PM, Maxence Guesdon wrote: > On Fri, 19 Sep 2008 11:20:36 -0700 > "Nathaniel Gray" wrote: >> >> For any identifier it would be good to know: >> 1. Its inferred type >> 2. Its fully-qualified module "path" > > All identifiers have not a fully qualified path (think of y in > let x = let y = ... in ...) That's a good point. I tend to think of those variables as being private parts of the current module, but perhaps that's inaccurate. So we can amend this request to be for "its fully qualified module path, if such a path exists". > and two identifiers may have the same > fully-qualified path. (e.g.: let x = 1;; let x = 2;;) That's fine. Nobody said it had to be unique. :) >> 3. Where it was defined, if it was defined in the current file. > > Would it be possible to have the location of the definition of all > identifiers, including the ones defined in another module (if there is > a .annot file for this module, of course) ? This strikes me as being beyond the scope of what the compiler can reasonably provide. If we're given the info that: 1. x resolves to Foo.Bar.x 2. Foo.Bar came from file /home/n8gray/src/foo/bar.cmo We can write the code that decides whether/how to find bar.annot, since that will be very build-system dependent. >> In addition, for each module referenced in the file it would be good >> to know what file the module was read from. (This will allow some >> hope of tracking down definitions in other files) >> >> It's hard for me to think of anything else that belongs in .annot >> files. If I stretch a bit I suppose annotating variable definitions >> with their range of scope might be cute. Maybe other people can think >> of more original ideas. > > A module containing the functions to read .annot files, so that > all developers using these files do not develop their own module. I agree, but this is something that can be developed outside the INRIA team if necessary. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->