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: [Caml-list] Re: Extending .annot files
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