English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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: 2008-09-24 (07:50)
From: Nathaniel Gray <n8gray@g...>
Subject: Re: [Caml-list] Extending .annot files
On Sun, Sep 21, 2008 at 11:08 PM, Maxence Guesdon
<maxence.guesdon@inria.fr> wrote:
> On Fri, 19 Sep 2008 11:20:36 -0700
> "Nathaniel Gray" <n8gray@gmail.com> wrote:
>> For any identifier it would be good to know:
>> 1. Its inferred type
>> 2. Its fully-qualified module "path"
> All identifiers have not a fully qualified path (think of y in
>  let x = let y = ... in ...)

That's a good point.  I tend to think of those variables as being
private parts of the current module, but perhaps that's inaccurate.
So we can amend this request to be for "its fully qualified module
path, if such a path exists".

> and two identifiers may have the same
> fully-qualified path. (e.g.: let x = 1;; let x = 2;;)

That's fine.  Nobody said it had to be unique.  :)

>> 3. Where it was defined, if it was defined in the current file.
> Would it be possible to have the location of the definition of all
> identifiers, including the ones defined in another module (if there is
> a .annot file for this module, of course) ?

This strikes me as being beyond the scope of what the compiler can
reasonably provide.  If we're given the info that:

1. x resolves to Foo.Bar.x
2. Foo.Bar came from file /home/n8gray/src/foo/bar.cmo

We can write the code that decides whether/how to find bar.annot,
since that will be very build-system dependent.

>> 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)
>> 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.
> A module containing the functions to read .annot files, so that
> all developers using these files do not develop their own module.

I agree, but this is something that can be developed outside the INRIA
team if necessary.


>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->