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.2 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 94DA7BB84 for ; Wed, 24 Sep 2008 18:19:37 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8DAMoF2kjRVdkPgGdsb2JhbACMDoZcPgEBFCShG2uHXQEC X-IronPort-AV: E=Sophos;i="4.33,301,1220220000"; d="scan'208";a="29543679" Received: from mail-gx0-f15.google.com ([209.85.217.15]) by mail4-smtp-sop.national.inria.fr with ESMTP; 24 Sep 2008 18:19:36 +0200 Received: by gxk8 with SMTP id 8so5783720gxk.3 for ; Wed, 24 Sep 2008 09:19:36 -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=rtpzi/U1I/O9mpYtWAYhRVzyMC4VEh87L25wDq6TYlw=; b=mA5W5UZl18jUPT+UxRQL7Ln/nlwAV41nNZnhrSeMyWDwi0rHuD664mC3Xv+HbGp+sK yI3iIv5QZqoekLJzvCDhZLJ2JZ0pkWXBNP8E/R56ZnucWoh+r0eEgntm7vAilAPwaVZH Z0ps7ymDi4Tosj6lNFRNafhW7XESAVaQyDYwo= 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=UdDxQpmYzNm8swvEjNcg/jqNIsQhCE5UKswJyDx491+TiGtrLTY5PL2m9EZDlgHlg6 g/Cd2gGDpNTjhxLK89t54RUpNMi0fvhrntaKPSaicc+EnPnVS8ZwIAiUtlQ8yNotqaIv Wv/6NLoeslsapR0FHqyPI85BIS6Sn3xs+0E0A= Received: by 10.151.112.4 with SMTP id p4mr1202474ybm.115.1222273176058; Wed, 24 Sep 2008 09:19:36 -0700 (PDT) Received: by 10.150.154.20 with HTTP; Wed, 24 Sep 2008 09:19:35 -0700 (PDT) Message-ID: <5160b4200809240919i659f9ee5oc2fd13d0db763553@mail.gmail.com> Date: Thu, 25 Sep 2008 01:19:35 +0900 From: "Jun Furuse" To: "Nathaniel Gray" Subject: Re: [Caml-list] Re: Extending .annot files Cc: caml-list@yquem.inria.fr In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5160b4200809211915n6884f1f4ref75c273cb5020fd@mail.gmail.com> X-Spam: no; 0.00; furuse:01 furuse:01 compilation:01 ocaml:01 compiler:01 ocaml:01 compilation:01 makefiles:01 functor:01 parser:01 emacs:01 parser:01 annotations:01 compiler:01 ad-hoc:01 Hi, >> In addition, ocamlspot records the following: >> - compilation load paths to find referred modules > > Is this different from my last sentence? I'm not sure if you mean the > path to the module file or the module search path. I would personally > rather have the path to the specific file for each module so that the > client doesn't have to write code for searching out modules. Yeah, if we recode module file path names, search paths are no longer required. But it is very easy to find annotation files in search paths, only if our external tool is written in OCaml and uses compiler modules. (And I explain why the first external tool should be written in OCaml later.) BTW, having module search paths and compilation options in the annotation files opens a door to more evil hacks: possibility of easy flymake style recompilation of source files without accessing Makefiles. :-) >> - abstractions of internally defined modules to find definitions of >> variables obtained from module aliases and functor applications > > Are there cases where you can't figure this out by following back the > chain of definitions? Yes, they are required for definition point analysis at queries. > Marshalled values are awful for .annot files because only OCaml code > can read them without lots of effort. I'd venture a guess that most > people want to exploit .annot files in their text editors. My text > editor isn't (yet) written in OCaml, and I know I'm not the only one. I am not enforcing you to write any parser of marshalled values in your editor extension language :-) I cannot do it! Instead, you can easily write a small OCaml program to dump it to whatever friendly to you and your editor, say, s-exp for emacs, or XML for some crazy editor. Then it should be easier to write a parser for the dump in your editor language than writing a parser for some fixed textual format which may not match with your editor language. I push marshalled values also since I have a plan to use recorded type expressions in annotations like ocamlbrowser. Of course marshalled values have downsides: annotation files become compiler version dependent. But I think we can avoid this problem somehow carefully choosing data types we output_value, as far as the compiler keeps the format of marshalled values and changes at type expression structures are small. We are discussing an official OCaml compiler extension in future, and I think it is very important to keep such an extensions small as possible; it is natural that INRIA people (and any other compiler developer) reject any extension not maintainable by themselves or something which adds extra library or tool requirements to the compiler itself. Therefore our extension should write down things available for free at compile time to the annotation files very simply. Any other work required can be done by external tools such as ocamlspot: definition location analysis over modules, compression, checking annotation file time stamps, and dumping them to editor friendly formats, and so on. I wrote ocamlspot in the above way, but some are still very ad-hoc. Upcoming beta2 version will be cleaner and have an example of textual dump. Regards, = j