caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Jun Furuse" <jun.furuse@gmail.com>
To: "Nathaniel Gray" <n8gray@gmail.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Re: Extending .annot files
Date: Thu, 25 Sep 2008 01:19:35 +0900	[thread overview]
Message-ID: <5160b4200809240919i659f9ee5oc2fd13d0db763553@mail.gmail.com> (raw)
In-Reply-To: <aee06c9e0809240033j7bb5f7beq5c39ca64773d78ac@mail.gmail.com>

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


  reply	other threads:[~2008-09-24 16:19 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
2008-09-24  7:33   ` [Caml-list] " Nathaniel Gray
2008-09-24 16:19     ` Jun Furuse [this message]
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=5160b4200809240919i659f9ee5oc2fd13d0db763553@mail.gmail.com \
    --to=jun.furuse@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=n8gray@gmail.com \
    /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).