Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Alain Frisch <alain@frisch.fr>
Cc: Jon Harrop <jon@ffconsultancy.com>, caml-list <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] Favorite OCaml editor?
Date: Tue, 05 Jan 2010 14:11:49 +0100	[thread overview]
Message-ID: <1262696874-sup-2960@peray> (raw)
In-Reply-To: <4B4337F4.4070407@frisch.fr>

Excerpts from Alain Frisch's message of Tue Jan 05 14:00:36 +0100 2010:
> On 05/01/2010 11:44, Nicolas Pouillard wrote:
> > Reusing the work done in the Yi [1][2] editor for the Haskell syntax should
> > be pretty straightforward. Very long and painful however due to the complexity
> > of the grammar of a real language.
> >
> > [1]: http://www.haskell.org/haskellwiki/Yi
> > [2]: http://www.cse.chalmers.se/~bernardy/FunctionalIncrementalParsing.pdf
> 
> Thanks for the links. The paper is a very interesting reading indeed. 
> Its main focus is on incrementality (not reparsing the whole buffer at 
> every keystroke). I'm not so sure how important it is in the context of 
> the current discussion though: I guess that with an efficient parsing 
> technology and modern computers, parsing even a big buffer at every 
> keystroke should be fast enough. Trivial optimizations like storing the 
> internal state of the parser at some point could also be used if needed.

Hum I doubt, or maybe you are prepared to accept more penalty than I do
(I consider Emacs to be noticeably slower than Vim on keystrokes, but
please don't feed the troll).

> I'm more concerned about the error recovery aspect; the paper suggests 
> the use of annotated error recovery rules, but writing them for a 
> grammar like OCaml's does not seem an easy task at all.

Indeed this is really a manual process but incrementally adding the rules
seemed to work. Actually this is a really visual process.

-- 
Nicolas Pouillard
http://nicolaspouillard.fr


  reply	other threads:[~2010-01-05 13:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-05  6:03 Grant Rettke
2010-01-05  6:08 ` [Caml-list] " Mihamina Rakotomandimby
2010-01-05  6:22 ` Mike Lin
2010-01-05  6:36   ` Alexander Voinov
2010-01-05  7:01   ` Erik de Castro Lopo
2010-01-05  7:31 ` Daniel Bünzli
2010-01-05 11:28   ` Jon Harrop
2010-01-05 16:55     ` Laurent Le Brun
2010-01-05  8:13 ` Jon Harrop
2010-01-05 10:27   ` Alain Frisch
2010-01-05 10:44     ` Nicolas Pouillard
2010-01-05 13:00       ` Alain Frisch
2010-01-05 13:11         ` Nicolas Pouillard [this message]
2010-01-05 14:14     ` Hugo Ferreira
2010-01-05  8:45 ` Maxence Guesdon
2010-01-05 11:23   ` Jon Harrop
2010-01-05 10:50     ` Maxence Guesdon
2010-01-05 10:24 ` Vincent Aravantinos
2010-01-05 11:02   ` Richard Jones
2010-01-05 10:58 ` Richard Jones
2010-01-05 12:21 ` Florent Ouchet
2010-01-05 17:32   ` Tim Hanson
2010-01-05 13:09 ` Martin DeMello
2010-01-05  6:21 Gaius Hammond

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=1262696874-sup-2960@peray \
    --to=nicolas.pouillard@gmail.com \
    --cc=alain@frisch.fr \
    --cc=caml-list@yquem.inria.fr \
    --cc=jon@ffconsultancy.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