caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: caml users <caml-list@inria.fr>
Cc: "Frédéric Bour" <frederic.bour@lakaban.net>
Subject: Re: [Caml-list] [ANN] Beta-release of Merlin
Date: Thu, 21 Feb 2013 10:20:44 +0100	[thread overview]
Message-ID: <CAPFanBE50071PpJkM03gu3q6PeTYqrFk=JLakLoCn1OzpiGErQ@mail.gmail.com> (raw)
In-Reply-To: <512557EB.7030607@lakaban.net>

[-- Attachment #1: Type: text/plain, Size: 5526 bytes --]

I looked into Merlin in the last few days, so here is a bit more
information if you, like me, are interested in design information about
projects before deciding whether to use (and potentially contribute to)
them.

Interface-wise: using Merlin (at least on emacs) feels a lot like
ProofGeneral (or CoqIde): there is a "checked zone" from the start of the
buffer to the first error, and reliable type information is available in
all this checked zone. The interface is rather simple and easy to use.

(If you're considering porting Merlin to another editor: merlin is an OCaml
program that inputs and outputs JSON queries, so it seems rather easy to
port to any editor having plugin support in any language with JSON support.
Given its youth, you should however expect Merlin's protocol to evolve over
the next development period, so editor plugin developers would need to
follow Merlin's internal changes for now.)

The major difference between Merlin and -annot-based tools such as
Ocamlspotter or Typerex2 is that Merlin does the work of parsing OCaml
sentences into chunks and sending them incrementally to the type-checker,
instead of sending the whole buffer at once and using the output. This
means that Merlin is much more robust with respect to files that have
errors and cannot be compiled as a whole: you'll get reliable type
information from the start of the file upto the first error (and some
resilience heuristic to have more after). The OCaml type-checker is in fact
able to provide some typing information even for incorrect programs, so
-annot-based tools do support some of those features, but in a less
reliable and more coarse-grained way.
The design trade-off is that Merlin has to copy/adapt more logic from the
compiler: it embeds an OCaml parser derived from the compiler's one (you
won't get parsing bugs as with regexpy elisp modes), and currently also
copies and slightly modifies the type-checker (I hope this can be changed
in the future, possibly by adding some flexibility to the type-checker
regarding eg. production of warnings). This means more maintenance work to
port Merlin to future OCaml versions. On the other hand, it's probably not
reasonable to expect the compiler type-checker to be re-engineered for
optimal incrementality support, so having an external implementation of
incrementality that piggybacks on the batch typer interface makes sense.

My personal intuition is that Merlin's design is a good long-term choice
for an editor service (as opposed to code-analysis services). You want
tools such as ocamldoc, dead code analysis, or everything concerned with
analysis of an existing correct codebase to be based on -bin-annot and work
on the typedtrees directly (without local support for parsing and typing
programs). You want tools designed to work on incomplete programs in the
process of being created to embed incrementality logic (insofar as it
hasn't been pushed into the compiler), understanding partial files and
local modifications to cleverly control the parsing&typing process with
reactivity in mind. The One True Editor Mode will merge both aspects,
working on .cmt of already-compiled dependencies on one side, and
partial/incremental information in edition buffers on the other. Merlin can
evolve in this way, as its type-directed analyses (those performed in the
"checked zone") work directly on the typedtree, so could work with .cmt
files.

On Thu, Feb 21, 2013 at 12:10 AM, Frédéric Bour
<frederic.bour@lakaban.net>wrote:

> We are very pleased to announce the beta release of Merlin. Merlin is a
> tool
> which provides smart completion, among other things, in your favorite
> editor.
> As of today, Vim and Emacs are supported.
>
> See it at work:
> https://github.com/def-lkb/**merlin#screenshots<https://github.com/def-lkb/merlin#screenshots>
>
> Its features include:
> - completion of values, constructorsand modules based on local scope
> - retrieving type of identifiers and/or expressions under cursor
> - integration of findlib to manage buildpath
> - highlighting of syntax errors, type errors and warnings inside the editor
> - to a certain amount, resilience to syntax and type errors
>
> It works only with Ocaml 4.00.1 (may works with newer versions).
>
> If you happen to have an opam installation with the right version
> (opam switch 4.00.1), you can try it right away with:
>
> $ opam remote add kiwi http://kiwi.iuwt.fr/~asmanur/**opam/.git<http://kiwi.iuwt.fr/~asmanur/opam/.git><
> http://kiwi.iuwt.fr/%**7Easmanur/opam/.git<http://kiwi.iuwt.fr/%7Easmanur/opam/.git>
> >
> $ opam install merlin
>
> Then to get started and set-up your editor:
> - https://github.com/def-lkb/**merlin#setting-up-vim<https://github.com/def-lkb/merlin#setting-up-vim>
> - https://github.com/def-lkb/**merlin#emacs-interface<https://github.com/def-lkb/merlin#emacs-interface>
>
> Check it out at: https://github.com/def-lkb/**merlin<https://github.com/def-lkb/merlin>
>
> The current version still needs to be tested under various systems and
> configurations, your feedback iswelcome.
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/**arc/caml-list<https://sympa.inria.fr/sympa/arc/caml-list>
> Beginner's list: http://groups.yahoo.com/group/**ocaml_beginners<http://groups.yahoo.com/group/ocaml_beginners>
> Bug reports: http://caml.inria.fr/bin/caml-**bugs<http://caml.inria.fr/bin/caml-bugs>
>

[-- Attachment #2: Type: text/html, Size: 6284 bytes --]

  reply	other threads:[~2013-02-21  9:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-20 23:10 Frédéric Bour
2013-02-21  9:20 ` Gabriel Scherer [this message]
2013-02-21  9:31   ` Simon Cruanes

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='CAPFanBE50071PpJkM03gu3q6PeTYqrFk=JLakLoCn1OzpiGErQ@mail.gmail.com' \
    --to=gabriel.scherer@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=frederic.bour@lakaban.net \
    /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).