Re: [Caml-list] How to write an efficient interpreter

[Diego Olivier Fernandez Pons <dofp.ocaml@gmail.com>]

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

    List,

Thanks for your suggestions, here is a small summary of them with some
comments.

Options for interpreting a DSL
-------------------------------------------

1 - Classical optimised interpreter
2 - Combinator / partial application based interpreter
3 - Emitting bytecode for any VM
4 - Emitting Caml source and compile / run on the fly
5 - Retargeting Caml compiler (CamlP4 syntax extension + custom toplevel)

Comments
----------------

1. Is the most natural and first thing to try (working on optimising my
naive interpreter right now)

5. Is the second most obvious idea : in the same way C is a portable
assembler, core-ML is a portable functional language. If we could easily
write a Lex/Yacc parser and generate Caml AST or some kind of quote and
connect it to Caml, we could interpret many DST with little work. Moreover,
generating Caml source is useful for debugging or profiling and can be
compiled offline.

One comment is that Lex/Yacc is a tool that any engineer can manage while
CamlP4 is much more complex which increases maintainability risks.

4. Is the poor man's variant of 5.

2. Globally the idea is that evaluating Plus (Plus (Var "x", 3), 4) is
slower than calling sum [| get env "x"; 3 ; 4 |] with a pre-compiled 'sum'
function.

There is already an interpreter for that same language that is targets C++
combinators : operator overloading and class hierarchy build an "AST" (2 + 3
* x -> expr<int>) which instantiates a set of predefined operators (sum,
forall, etc). The experience was however not good IMHO : despite a (naive)
gc there are still permanent memory leaks and speed issues, part of the
semantics is lost which requires some guessing, there are weird limitations
like polymorphism that only works with 2 levels of nesting, finally the code
basis grows uncontrollably. Maybe C++ is to blame there. In any case that's
a second level of optimisation after 1.

3. Unless there is a 3rd part tool to emit the code, I won't get into this.
It would allow native interaction with the customer chosen platform (Java,
.NET, etc) but that's way too much trouble and risk as long as it is not a
standard technique that any engineer can handle.

        Diego Olivier

[-- Attachment #2: Type: text/html, Size: 2668 bytes --]