Version française
Home     About     Download     Resources     Contact us    
Browse thread
OCamlDuce 3.08.4
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Alain Frisch <Alain.Frisch@i...>
Subject: Re: [Caml-list] OCamlDuce 3.08.4
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