caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Jun Furuse" <jun.furuse@gmail.com>
To: caml-list@yquem.inria.fr
Subject: Re: Extending .annot files
Date: Mon, 22 Sep 2008 11:15:07 +0900	[thread overview]
Message-ID: <5160b4200809211915n6884f1f4ref75c273cb5020fd@mail.gmail.com> (raw)
In-Reply-To: <aee06c9e0809191120i33409998i8335e7f5392b92b1@mail.gmail.com>

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


  reply	other threads:[~2008-09-22  2:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-19 18:20 Nathaniel Gray
2008-09-22  2:15 ` Jun Furuse [this message]
2008-09-24  7:33   ` [Caml-list] " Nathaniel Gray
2008-09-24 16:19     ` Jun Furuse
2008-09-22  6:08 ` [Caml-list] " Maxence Guesdon
2008-09-24  7:50   ` Nathaniel Gray

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5160b4200809211915n6884f1f4ref75c273cb5020fd@mail.gmail.com \
    --to=jun.furuse@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).