From: skaller <skaller@users.sourceforge.net>
To: Alain Frisch <Alain.Frisch@inria.fr>
Cc: Lukasz Stafiniak <lukstafi@gmail.com>, caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] OCamlDuce 3.08.4
Date: Sat, 27 Aug 2005 09:21:32 +1000 [thread overview]
Message-ID: <1125098492.25384.70.camel@localhost.localdomain> (raw)
In-Reply-To: <430F4BD9.5030007@inria.fr>
[-- 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 --]
prev parent reply other threads:[~2005-08-26 23:21 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
2005-08-26 23:21 ` skaller [this message]
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=1125098492.25384.70.camel@localhost.localdomain \
--to=skaller@users.sourceforge.net \
--cc=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