[ANN] ocamlgrep 0.1.1

[mjambon]

@nojb

@reynir

What is a bit surprising to me (but probably not a problem) is that it showed foo in the body of functions but not the (foo : Foo.t) argument further up in the function.

Currently we match the search term (which is syntactically an expression) against an expression in the source code. The (foo : Foo.t) argument is not syntactically an expression, but a pattern. I don’t see why we couldn’t match it as well, but it is not done at the moment.

If anyone is interested in tackling this, here are some ideas:

• optionally let the user specify the query kind (expression, pattern, top-level item, …) via a command-line option;
• if the query kind isn’t specified, try parsing the query both as an expression and as a pattern, resulting effectively in one or two queries depending on parsing success;
• I think it could be useful to scan for match cases such as | Foo _ -> Error (__ : string) but unfortunately, compiler-libs doesn’t offer an entry point for parsing just a match case. See what’s available in ocaml/parsing/parse.mli at trunk · ocaml/ocaml · GitHub

[mjambon]

@fantazio

You will probably find the information in cmt_infos.cmt_sourcefile. In your example, _build/test.cmt should point to tests/test.ml.

Yes, but this requires loading (at least partially) all the cmt files to determine which ones are relevant, right? I’m worried about performance when scanning small portions of large projects.

[dbuenzli]

@mjambon

This approach requires listing the files in each of the build dirs so we can fish out the relevant cmt files. Maybe this is fast enough on most projects, I don’t know.

Yes listing files is fast.

@mjambon

Providing such options on the command line would be a bit cumbersome, especially if this needs to be done every time when working on a given large project.

This kind of misses the point, just let me drive ocamlgrep the way I want :–) Command line tools are not necessarily invoked manually. It’s a bit like saying that providing -I options to ocamlc is a bit cumbersome because this needs to be done every time I want to build.

@mjambon

Yes, but this requires loading (at least partially) all the cmt files to determine which ones are relevant, right? I’m worried about performance when scanning small portions of large projects.

This is why I suggest to first match on file names and only load the .cmt files and check that field only on ambiguities. Except perhaps for that test.ml file, compilation unit names are reasonably unique.

[mjambon]

@dbuenzli I put a draft proposal at Add command-line interface to support arbitrary build systems. Please check if it looks about right.

[aryx]

Regarding semantic equivalences, the Coccinelle tool for C gives the ability to define “isomorphisms” (see. standard.iso ) so the user can define easily equivalences reusing the same syntax used for queries. The semgrep tool had a similar capability at some point but it got removed because no one was using the feature. It was pretty cool though (shoutout to Julia Lawall for the original idea).

The way it was implemented was to actually run the semgrep (or coccinelle) matching engine on the query itself (very meta) and rewrite the query as a set of disjunctive patterns (the matching language was expressive enough to support disjunction, conjonction, negation) by running the isomorphic rewrite rules on the query.