From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 1CD2F7FAEE for ; Tue, 18 Nov 2014 10:08:57 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.214.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.214.178 as permitted sender) identity=mailfrom; client-ip=209.85.214.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ob0-f178.google.com) identity=helo; client-ip=209.85.214.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-ob0-f178.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0GAAoMa1TRVdaym2dsb2JhbABbg2NZBIMCuQGOLoFeAQ2HRQIoYQcWAQEBAQERAQEBAQEGCwsJFC6DegkBAQQSER0BGx0BAwwGBQsNKgICIQEBEQEFARwZIoVUgjUBAxINrRg9MYs7gXODEYpMChknDWiFeAEBAQEGAQEBAQEBARUBBQ6KYoNdHYIaBAeCNkEPA4FCBYUpAoZrii9nhRaCFIEzPY1MSIJsgg4YKYVTHzABgkoBAQU X-IPAS-Result: Ao0GAAoMa1TRVdaym2dsb2JhbABbg2NZBIMCuQGOLoFeAQ2HRQIoYQcWAQEBAQERAQEBAQEGCwsJFC6DegkBAQQSER0BGx0BAwwGBQsNKgICIQEBEQEFARwZIoVUgjUBAxINrRg9MYs7gXODEYpMChknDWiFeAEBAQEGAQEBAQEBARUBBQ6KYoNdHYIaBAeCNkEPA4FCBYUpAoZrii9nhRaCFIEzPY1MSIJsgg4YKYVTHzABgkoBAQU X-IronPort-AV: E=Sophos;i="5.07,408,1413237600"; d="scan'208";a="107828152" Received: from mail-ob0-f178.google.com ([209.85.214.178]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 18 Nov 2014 10:08:55 +0100 Received: by mail-ob0-f178.google.com with SMTP id gq1so3631495obb.23 for ; Tue, 18 Nov 2014 01:08:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=ry8W6HODSzF8iYlVECB6TIPik5cVwAaCVDDeYUT5Naw=; b=Jg9R6qDB/9oS9OzU0AanpFV5Q6yWFyQwboTuhOKIp7RED6shBdcPhbEkePXMLqXrlm WP+94gYiVHnzDaZ5afnrdwoez8yRo1FeZBEWdz7LSPpGs6eEDEpFaof1tJSi7mT0kcJG mdRmrnc69GOT2BVUQSWgRDuEAxm0D46yqKqDN9YJF5gTFJsEAVaQE7+FiXmK/Un4P567 lqt/0d32VGwfjHmVqmQ2k+LgRilnuQikZB81esl3tfDRwhqjyug8IM3ShLlFnrnmh5ts gCuXlQWUdvLHXP/7ZgjnJI60+MuiJRrkSgxtVc4V17PtiChD2OHqe/AryhIekis7BSPj YpqQ== MIME-Version: 1.0 X-Received: by 10.182.33.67 with SMTP id p3mr29387308obi.15.1416301734656; Tue, 18 Nov 2014 01:08:54 -0800 (PST) Received: by 10.182.197.1 with HTTP; Tue, 18 Nov 2014 01:08:54 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Nov 2014 04:08:54 -0500 Message-ID: From: Kenneth Adam Miller Cc: caml users Content-Type: multipart/alternative; boundary=001a11c1e8d0ca017c05081e71ac Subject: Re: [Caml-list] Go Oracle like facility for Ocaml? --001a11c1e8d0ca017c05081e71ac Content-Type: text/plain; charset=UTF-8 Wow, you did a fantastic job fielding this question. I only even found one of those tools, OCamlspotter and some etags, otags and cscope functionality! :) On Tue, Nov 18, 2014 at 4:06 AM, Gabriel Scherer wrote: > (One can find a description of Go oracle's design in > > https://docs.google.com/document/d/1WmMHBUjQiuy15JfEnT8YBROQmEv-7K6bV-Y_K53oi5Y/view > and its user manual in > > https://docs.google.com/document/d/1SLk36YRjjMgKqe490mSRzOPYEDe0Y_WQNRv-EiFYUyw/view#heading=h.kthq8ap0mdwi > ) > > The ecosystem of OCaml tooling is not as refined as Go's (but > contributions are welcome). There is no centralized tool provider with > a common interface, but several contributors have developped separate > tool to anayze different aspects of OCaml programs: > > - ocamlspotter: https://bitbucket.org/camlspotter/ocamlspot > - ocp-index: http://typerex.ocamlpro.com/ocp-index.html > - pfff: https://github.com/facebook/pfff > - merlin: http://the-lambda-church.github.io/merlin/ > > These tool provide a relatively complete coverage of the information > that can easily be retrieved from the typedtree of a program (>=4.01 > versions of the OCaml compiler have the option to generate a reified > typedtree for external tools): the occurences of a declared/defined > name, the definition place of a name, the type of an expression, etc. > As far as I'm aware, there is not much in the direction of the more > advanced static analysis feature Go's oracle supports: points-to > information, "who may update this mutable field", etc. I'm not > familiar with Pfff's capabilities, it may be the more advanced in this > regard. > > (There is also more experimental work going on, for example Thomas > Blanc's work on static analysis of exception flow at OCamlPro: > https://github.com/OCamlPro/socaml-analyzer ) > > I think merlin is the best-positioned tool to deal with > partially-incorrect files (typical of an edition session) and > incrementality. It also incorporates some query/analysis feature, but > it's unclear whether those should grow inside a monolithic tool (eg. > it could encompass the current feature set of ocp-index and > ocamlspotter, if it does not already), or rather try to communicate > with external analysis/query plugins. It also interacts with existing > editors through a reasonable query-answer interface, but does not > provide a direct command-line interface (anyone interested in this > could work on it, it may be relatively easy to implement). > > There are fairly orthogonal aspects to a "answering questions about > programs" toolbox, among which: > 1) user-interface, interactive use, and interface with existing editors > 2) support for incrementality and robustness under partially-incorrect > files > 3) knowledge of what the "project", or whole program, is; which > dependencies are required to understand the work? (build system > knowledge) > 4) implementation of various program analyses and transformations > > Is it possible to provide them in separate programs and have them > interact to form a useful whole? Or would it be easier, faster and > more robust to implement them all in a monolithic program? What are > the necessary interdependence between these aspects and what interface > should them provide to each other? > > On Tue, Nov 18, 2014 at 6:00 AM, Kenneth Adam Miller > wrote: > > If anybody knows what Go's oracle is you'll know that its a great > > accelerator for your time; it allows expressive and meaningful searches > to > > be done over a source repository. It's fast and dead useful. Opengrok is > > much the same, but to a lesser extent (having links is nice, but not > quite > > as powerful as oracle, I could be wrong). > > > > Is there anything like this for OCaml? > --001a11c1e8d0ca017c05081e71ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wow, you did a fantastic job fielding this question. I onl= y even found one of those tools, OCamlspotter and some etags, otags and csc= ope functionality! :)

On Tue, Nov 18, 2014 at 4:06 AM, Gabriel Scherer <gabrie= l.scherer@gmail.com> wrote:
(One can find a description of Go oracle's design in
=C2=A0 https://docs.google.com/docu= ment/d/1WmMHBUjQiuy15JfEnT8YBROQmEv-7K6bV-Y_K53oi5Y/view
and its user manual in
=C2=A0 htt= ps://docs.google.com/document/d/1SLk36YRjjMgKqe490mSRzOPYEDe0Y_WQNRv-EiFYUy= w/view#heading=3Dh.kthq8ap0mdwi
)

The ecosystem of OCaml tooling is not as refined as Go's (but
contributions are welcome). There is no centralized tool provider with
a common interface, but several contributors have developped separate
tool to anayze different aspects of OCaml programs:

- ocamlspotter: https://bitbucket.org/camlspotter/ocamlspot
- ocp-index: http://typerex.ocamlpro.com/ocp-index.html
- pfff: http= s://github.com/facebook/pfff
- merlin: http://the-lambda-church.github.io/merlin/

These tool provide a relatively complete coverage of the information
that can easily be retrieved from the typedtree of a program (>=3D4.01 versions of the OCaml compiler have the option to generate a reified
typedtree for external tools): the occurences of a declared/defined
name, the definition place of a name, the type of an expression, etc.
As far as I'm aware, there is not much in the direction of the more
advanced static analysis feature Go's oracle supports: points-to
information, "who may update this mutable field", etc. I'm no= t
familiar with Pfff's capabilities, it may be the more advanced in this<= br> regard.

(There is also more experimental work going on, for example Thomas
Blanc's work on static analysis of exception flow at OCamlPro:
h= ttps://github.com/OCamlPro/socaml-analyzer )

I think merlin is the best-positioned tool to deal with
partially-incorrect files (typical of an edition session) and
incrementality. It also incorporates some query/analysis feature, but
it's unclear whether those should grow inside a monolithic tool (eg.
it could encompass the current feature set of ocp-index and
ocamlspotter, if it does not already), or rather try to communicate
with external analysis/query plugins. It also interacts with existing
editors through a reasonable query-answer interface, but does not
provide a direct command-line interface (anyone interested in this
could work on it, it may be relatively easy to implement).

There are fairly orthogonal aspects to a "answering questions about
programs" toolbox, among which:
1) user-interface, interactive use, and interface with existing editors
2) support for incrementality and robustness under partially-incorrect file= s
3) knowledge of what the "project", or whole program, is; which dependencies are required to understand the work? (build system
knowledge)
4) implementation of various program analyses and transformations

Is it possible to provide them in separate programs and have them
interact to form a useful whole? Or would it be easier, faster and
more robust to implement them all in a monolithic program? What are
the necessary interdependence between these aspects and what interface
should them provide to each other?

On Tue, Nov 18, 2014 at 6:00 AM, Kenneth Adam Miller
<kennethadammiller@gmail.= com> wrote:
> If anybody knows what Go's oracle is you'll know that its a gr= eat
> accelerator for your time; it allows expressive and meaningful searche= s to
> be done over a source repository. It's fast and dead useful. Openg= rok is
> much the same, but to a lesser extent (having links is nice, but not q= uite
> as powerful as oracle, I could be wrong).
>
> Is there anything like this for OCaml?

--001a11c1e8d0ca017c05081e71ac--