Re: [Caml-list] Re: Extending .annot files

["Nathaniel Gray" <n8gray@gmail.com>]

On Sun, Sep 21, 2008 at 7:15 PM, Jun Furuse <jun.furuse@gmail.com> 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 -->