Version française
Home     About     Download     Resources     Contact us    
Browse thread
Extending .annot files
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jun Furuse <jun.furuse@g...>
Subject: Re: Extending .annot files
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
- abstractions of internally defined modules to find definitions of
variables obtained from module aliases and functor applications
- 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,
corresponding .mli entry positions and so on. 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.

> 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.
Still, it is possible to reduce the size of annotation files, by
outputting as marshaled value, which makes things 35%, still more than
twice larger than the source :-(.

=
j