OCamlDuce 3.08.4

OCamlDuce 3.08.4

[Alain Frisch]

Dear OCaml users,

OCamlDuce 3.08.4 is now available (http://www.cduce.org/ocaml#ocaml).
As the version number says, it has been synchronized with OCaml 3.08.4.

More importantly and due to overwhelming popular demand, OCamlDuce now 
comes with some amount of binary-compatibility with OCaml. This should 
make it easier to try OCamlDuce.

OCaml-generated  files (.cmi/.cmx/.cmo) can be used by OCamlDuce without 
recompilation. You can thus install OCamlDuce and re-use already 
installed libraries from an existing OCaml installation. Provided that 
the OCaml and OCamlDuce versions match, of course.

It is even possible to have a mixed OCaml/OCamlDuce project, where 
OCamlDuce is only used to compile some modules whose interface are pure 
OCaml (OCaml and OCamlDuce produce identical .cmi files for the same 
pure OCaml .mli file).

Have fun!

-- Alain

Re: [Caml-list] OCamlDuce 3.08.4

[Alain Frisch]

skaller wrote:
> Just to confirm please, my understanding is that there is a good
> chance OcamlDuce will just become Ocaml (perhaps Ocaml 4.0?)

Not at all. Where did you get this impression?


-- Alain

Re: [Caml-list] OCamlDuce 3.08.4

[skaller]

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

On Wed, 2005-08-24 at 18:53 +0200, Alain Frisch wrote:
> Dear OCaml users,
> 
> OCamlDuce 3.08.4 is now available (http://www.cduce.org/ocaml#ocaml).
> As the version number says, it has been synchronized with OCaml 3.08.4.
> 
> More importantly and due to overwhelming popular demand, OCamlDuce now 
> comes with some amount of binary-compatibility with OCaml. This should 
> make it easier to try OCamlDuce.

Just to confirm please, my understanding is that there is a good
chance OcamlDuce will just become Ocaml (perhaps Ocaml 4.0?)


-- 
John Skaller <skaller at users dot sourceforge dot net>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] OCamlDuce 3.08.4

[skaller]

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

On Thu, 2005-08-25 at 20:53 +0200, Alain Frisch wrote:
> skaller wrote:
> > Just to confirm please, my understanding is that there is a good
> > chance OcamlDuce will just become Ocaml (perhaps Ocaml 4.0?)
> 
> Not at all. Where did you get this impression?

Don't know .. but then the question .. why not?

-- 
John Skaller <skaller at users dot sourceforge dot net>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] OCamlDuce 3.08.4

[Lukasz Stafiniak]

> On Thu, 2005-08-25 at 20:53 +0200, Alain Frisch wrote:
> > skaller wrote:
> > > Just to confirm please, my understanding is that there is a good
> > > chance OcamlDuce will just become Ocaml (perhaps Ocaml 4.0?)
> >
> > Not at all. Where did you get this impression?
> 
> Don't know .. but then the question .. why not?
> 
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.

Best Regards,
Lukasz

Re: [Caml-list] OCamlDuce 3.08.4

[Alain Frisch]

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

Re: [Caml-list] OCamlDuce 3.08.4

[skaller]

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

On Fri, 2005-08-26 at 19:05 +0200, Alain Frisch wrote:

> For what concerns John's question about the integration of OCamlDuce in 
> OCaml, there are many answers. 

.. and time to explore them. I wasn't trying to suggest the merger
should be done tomorrow (hence Ocaml 4.0 number ..)

>  3) OCaml is a general purpose language, and the extension adds support for 
> a specific domain 

Tree pattern matching isn't all that specific is it?

I mean one could argue regular patterns are a 'specific domain' ..
but one would be missing the fact the finite state automata are
in the basis of computing.

Ocaml can't even do regular matching, how on earth you could
call it a 'pattern matching language' I don't know. Yet CDuce
is already extending patterns well beyond mere regular matches
by providing fairly strong capturing ability.

> 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 

meaning {{ UGLY }} .. yes, it is ghastly.

> 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).

Agree. However, whenever you have two tools you have to join them
together somehow. One way of doing that is with Unix scripting,
shell scripts and the like. This is very ugly and non-portable,
but can usually be got to work. 

For example, using ocamllex/yacc is just horrible in practice,
in Felix compiler there are so many files just to glue them
together .. 

.. in Felix language itself both lexer and parser
tools are built in to the language and the compiler does the gluing.

Camlp4 provides some interesting ways to glue things in a much
more structured way than Unix script.

-- 
John Skaller <skaller at users dot sourceforge dot net>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]