From: Alain Frisch <Alain.Frisch@inria.fr>
To: Lukasz Stafiniak <lukstafi@gmail.com>
Cc: caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] OCamlDuce 3.08.4
Date: Fri, 26 Aug 2005 19:05:29 +0200 [thread overview]
Message-ID: <430F4BD9.5030007@inria.fr> (raw)
In-Reply-To: <4a708d20508251700632c6963@mail.gmail.com>
Lukasz Stafiniak wrote:
> What about a notion of supported extensions. These would not be
> included into the main distribution, but each of them would have a
> branch extending each other, so the user can bake any combination (or
> merger) of them.
That's interesting, but I don't know how this should work in practice.
Each extension might change in a significant way the type-checking
and/or code-generation passes. OCamlDuce affects the type-checker in a
very limited and modular way (except that two passes of the ML
type-checker are run sequentially), but other extensions might really
change in deeper ways the type algebra, the structure of the
type-checker, or other aspects of the implementation. There are both
theoretical issues (interaction of exotic type-checking features)
and practical ones (how to design an extensible compiler).
For what concerns John's question about the integration of OCamlDuce in
OCaml, there are many answers. 1) I'm not directly involved in the
development of OCaml. 2) The -Duce part, taken from CDuce, is a big
piece of code which still evolves in some experimental ways and which
couldn't be easily maintained by someone else in its current state. 3)
OCaml is a general purpose language, and the extension adds support for
a specific domain (and OCaml is already big enough). 4) One of the
design guidelines for OCamlDuce was to obtain an easy merger between two
existing implementations; due to this constraint the result is not as
elegant or integrated with the rest of the language as one might expect
from an ML+CDuce merger written from scratch (but it works). The
constraint of being able to compile any existing OCaml program with
OCamlDuce, for instance, resulted in the introduction of explicit
delimiters {{..}} for all the new constructions, which is syntactically
heavy and theoretically useless. 5) It's too early to say whether
OCamlDuce is useful or not compared to a simpler solution with two
compilers (OCaml, CDuce).
-- Alain
next prev parent reply other threads:[~2005-08-26 17:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-24 16:53 Alain Frisch
2005-08-25 18:53 ` [Caml-list] " skaller
2005-08-25 18:53 ` Alain Frisch
2005-08-25 19:18 ` skaller
2005-08-26 0:00 ` Lukasz Stafiniak
2005-08-26 17:05 ` Alain Frisch [this message]
2005-08-26 23:21 ` skaller
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=430F4BD9.5030007@inria.fr \
--to=alain.frisch@inria.fr \
--cc=caml-list@inria.fr \
--cc=lukstafi@gmail.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