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 D8F9EBB84 for ; Wed, 24 Sep 2008 09:33:33 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIBAAuK2UjRVcbslGdsb2JhbACSZz4BAQEBCQkMBxEDmwVrh2UBAg X-IronPort-AV: E=Sophos;i="4.33,299,1220220000"; d="scan'208";a="17679968" Received: from rv-out-0506.google.com ([209.85.198.236]) by mail1-smtp-roc.national.inria.fr with ESMTP; 24 Sep 2008 09:33:32 +0200 Received: by rv-out-0506.google.com with SMTP id f6so2309286rvb.3 for ; Wed, 24 Sep 2008 00:33:32 -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=DYmBTkCruwC+IjiD/hqYjxxEJ16JyGUyCnQZNle1Wsw=; b=jtv0WnkqCIcE1IyDP+3YXHWY/HX/7Ca2aKNOk6UX0Dibi5Cs78EefqjoVf8qirA9Ua JvfjYSbIkPO8EUZzl5D1OtVSzPVKT9m4aX/Qt8xXS4e4WIaii707jLnbatkmG4W02YAk 4J878x1jhGYS0vn3Huh5Z9Mues96F2L0JzY3Y= 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=J/R6vyGouivZXDM1/qsS2rVIP+7JyW0h9OOgZI5S4PvPWCG/9oPYu8WZB8iHP9AQqs ROe4ImTgFUbMbltJ07UVnk4qBB3HCWZcJlKraKL243j5tLx2F+dwOM7VfoTXIWiyl2tt yfRI6m/UHgPl76OoKzt4EQrhZin5DPz8wYYCo= Received: by 10.141.41.12 with SMTP id t12mr3254772rvj.282.1222241612047; Wed, 24 Sep 2008 00:33:32 -0700 (PDT) Received: by 10.141.123.21 with HTTP; Wed, 24 Sep 2008 00:33:32 -0700 (PDT) Message-ID: Date: Wed, 24 Sep 2008 00:33:32 -0700 From: "Nathaniel Gray" To: "Jun Furuse" Subject: Re: [Caml-list] Re: Extending .annot files Cc: caml-list@yquem.inria.fr In-Reply-To: <5160b4200809211915n6884f1f4ref75c273cb5020fd@mail.gmail.com> 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 compiler:01 compilation:01 functor:01 mli:01 compiler:01 camlp:01 compilation:01 marshaled:01 parsers:01 ocaml:01 ocaml:01 makefiles:01 gzipped:01 On Sun, Sep 21, 2008 at 7:15 PM, Jun Furuse wrote: > Hi, > >> I'm really happy to hear that you're open to including some of this >> stuff. I think there are actually only a few data that one wants to >> have in .annot files (and that the compiler can reasonably provide). >> >> For any identifier it would be good to know: >> 1. Its inferred type >> 2. Its fully-qualified module "path" >> 3. Where it was defined, if it was defined in the current file. >> >> 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) > > 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. > - 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? > - some hack for packed modules > >> 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. > > Many things: constructor/type/exception/module definition locations, Sure, by using the word "identifiers" above I meant to include these entities. > corresponding .mli entry positions and so on. That's a good idea, assuming the compiler has this information at the right time. > Some of them, especially > type related things, require compiler side support definitely, but the > others could be done by CamlP4 or something similar, I guess. I > personally like to modify the compiler since all the interesting > information is available at compilation for free and all we need is > just to export it to some file, in an extensible format. Probably in a > text file like the current annot, or as a marshaled value like > ocamlspot does. Marshalled values are nice since we do not need to > write parsers for them, and we can use lots of tool functions in the > compiler to handle them. But of course, it is more difficult to keep > backward compatibility, which Xavier is anxious about. 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. >> Finally, it may be worth putting a little work into reducing the size >> of .annot files. One could certainly do much better with very little >> effort. > > The size of the current annot files are more than 600% larger than the > source ml files (I measured this by compiling ocaml compiler tree with > -annot). Gzipping them makes them 1/10 (about 60% of the source size). > However, the compiler should not rely on any external compression tool > is available by default. You can easily add few rules to your OCaml > project Makefiles to gzip annots automatically, and I guess it would > be also easy to extend caml-types.el to support gzipped annot files. I recently pointed out this very fact about gzipping .annot files, but if we're putting together a wish list for .annot file changes I would still like to see them be less bloated by default. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->