caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Wojciech Meyer <wojciech.meyer@googlemail.com>
To: "Daniel Bünzli" <daniel.buenzli@erratique.ch>
Cc: Hongbo Zhang <bobzhang1988@gmail.com>,  caml-list@inria.fr
Subject: Re: [Caml-list] Re: Syntax extensions without Camlp4
Date: Sun, 27 May 2012 23:43:47 +0100	[thread overview]
Message-ID: <wf8vgd453w.fsf@gmail.com> (raw)
In-Reply-To: <71FFF6A2CF1E4E6DA0FFF397B2084B89@erratique.ch> ("Daniel \=\?utf-8\?Q\?B\=C3\=BCnzli\=22's\?\= message of "Sun, 27 May 2012 21:01:43 +0200")

Daniel Bünzli <daniel.buenzli@erratique.ch> writes:

>> I agree that it would be nice if we have metaocaml in.

Agreed.

> Why not. But metaocaml is not about static meta-programming, it provides abstractions for runtime meta-programming.

Runtime meta-programming is a generalisation of static meta
programming. MetaOCaml has a nice set of abstraction to generate
typechecking code - yes - either at runtime or during compile time. The
problem is that it's purely for partial evaluation and not extending the
syntax. Therefore the main purpose of syntactical abstraction is missing
- but that's not a problem - MetaOCaml wasn't designed for it.

Things that I would like to see in future "incarnation" or integrating of
meta programming facilities to the language  would be (beware that's my
blue dreams!):

- first of all non destructive updates to the grammar e.g: "let open
  lang Sexp in ..."  should open the Sexp syntax extension, install the
  grammar, but when it goes out of scope it should vanish. Currently
  Camlp4 can install, delete the rules after the functor is applied, and
  no way of saying OK - let's go back.

- Composable - in particular one language should behave like a module,
  or functor, should have an interface consisting of grammar rules, AST,
  AST transforms etc. So one could parametrise one syntax extension
  over another, and possibly reuse the language grammar or AST in
  other. Currently Camlp4 syntax extension is just a single separate
  module which when loaded possibly expects some existing grammar rules
  to be in place and mutates them as it's needed.

- should be type safe and as mentioned before obey scoping rules. We
  should be able to propagate type information even when the syntax
  changes. This is difficult part - but I've seen it can be done with some
  extra annotations - not talking about Camlp4

- Recursive - it should be able to apply the grammar rules not only
  once but expand until it reached the fixpoint.

- Reflective - it should be possible after each successful expansion have
  the type information available for the next expansion.

- Grammar itself should be lexer-less - memoizing PEG with left
  recursion - it's hurdle to define new grammar in terms of old lexer,
  or having a stateful lexer that depends on context.

- It should not be external tool - like previously observed - it's
  difficult to support for code highlighters or refactoring (tools in
  general) - if it depends on a build step or command line options.

That's said I find Camlp4 extremely useful for code generation purposes
- when I need to generate some ML code through quotations. Also, some
very important projects depend on Camlp4 (or Camlp5) like Coq. I don't
see that ML can live without some meta programming facilities out of the
box.

-- 
Wojciech Meyer
http://danmey.org

  reply	other threads:[~2012-05-27 22:43 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-27 15:06 [Caml-list] " Alexandre Pilkiewicz
2012-05-27 16:53 ` [Caml-list] " Hongbo Zhang
2012-05-27 18:04   ` Daniel Bünzli
2012-05-27 18:18     ` Hongbo Zhang
2012-05-27 19:01       ` Daniel Bünzli
2012-05-27 22:43         ` Wojciech Meyer [this message]
2012-05-28  9:35           ` Daniel Bünzli
2012-05-28  9:59             ` Gabriel Scherer
2012-05-30 14:45               ` Hongbo Zhang
2012-05-28 11:17             ` Wojciech Meyer
2012-05-28 15:52             ` Jeffrey Scofield
2012-05-27 18:19     ` Hongbo Zhang
2012-05-28  8:17     ` Paolo Donadeo
2012-05-30 12:41   ` Alain Frisch
2012-05-30 13:18     ` Markus Mottl
2012-05-30 13:37     ` Dan Bensen
2012-05-30 14:16       ` Hongbo Zhang
2012-05-30 14:23         ` Paolo Donadeo
     [not found]           ` <20120531081913.GA26742@securactive.lan>
2012-05-31 12:26             ` Paolo Donadeo
2012-05-31 12:38               ` Anil Madhavapeddy
2012-05-31 12:40                 ` Anil Madhavapeddy
2012-05-31 12:46                   ` Yaron Minsky
2012-05-31 12:47                   ` Gabriel Scherer
2012-05-31 22:08                 ` Paolo Donadeo
2012-05-30 14:14     ` Hongbo Zhang
2012-05-31 12:59       ` Alain Frisch
2012-05-31 13:21         ` Dmitry Grebeniuk
2012-05-31 14:30           ` Daniel Bünzli
2012-05-31 16:01         ` bob zhang
2012-05-31 17:28           ` Gerd Stolpmann
2012-05-31 18:03             ` Wojciech Meyer
2012-05-31 18:32               ` Gerd Stolpmann
2012-05-31 18:32             ` Hongbo Zhang

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=wf8vgd453w.fsf@gmail.com \
    --to=wojciech.meyer@googlemail.com \
    --cc=bobzhang1988@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=daniel.buenzli@erratique.ch \
    /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).