Re: [Caml-list] 'Compiler' module

[Dawid Toton <dawid.toton@uj.edu.pl>]

> 
> Given that the sole objective of run-time compilation is performance and 
> Python is vastly slower than OCaml, why are you the envy of Python's Compiler 
> (to interpreted bytecode) module?
> 

 From my point of view this is more about manipulating code at runtime
and evaluating it (actually I'm not interested about performance).


> I think (as Zheng implied) you want asynchronous workflows from F#. Note that 
> these also handle cleanup of resources.

 From what is currently available on web I see that it's equivalent to
my current stop-gap solution using monads:
(async {blah blah}) in F# can be translated to (lazy (blah blah)) in
OCaml and Async.Run just uses some threads to do Lazy.force. Am I
missing some difference?

> 
> For a decent editor, you will need a lot more than that. I would certainly 
> love to have such a thing but you also need access to the type checking phase 
> to throwback type errors and having the data available in an efficient and 
> accessible form would certainly be preferable.
> 

I see no reason for hypothetical Compiler.eval function couldn't give me
full information about all errors.

As for availability of resulting data: this is not obvious at the
conceptual level.

One possibile solution is to decide that the host invoking Compiler.eval
has to treat resulting values as of abstract type. They might be subject
to marshalling and so on.

The other way is to have a module for manipulating data which type is
known at runtime. Then Compiler.eval would return value of type
TypedData.t = (Type.t, TypedData.abstract_type)

The second approach would make the whole Compiler-module-thing more useful.

Anyway, this is somewhat another story. RTTI would allow us to have
clean implementation of marshalling. We could have (at no performance
cost) Type.typeof operator that acts only on values of concrete type
(if only camlp4 knew types...).

> I believe you can lex and parse OCaml using Camlp4 and then invoke the OCaml 
> compiler with -dtypes to get the results of type checking. However, the 
> latter is extremely inefficient. You really want the ability to restart the 
> compiler from the end of the previous definition each time a file is edited.

I hope the first dirty solution would be to use compiled modules as the
context carrier. In case of a simple editor I'd have many tiny modules
that correspond to compiled chunks of evolvong code.
It would scale not so bad: compiler would have to load (log n) modules
for n chunks processed. But I have no idea what would be the practical
performance.

Dawid