From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id CF024BB84 for ; Mon, 6 Oct 2008 19:15:41 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUDADfk6UiVnFmTiGdsb2JhbACTYQEBARUionmFBjyBag X-IronPort-AV: E=Sophos;i="4.33,368,1220220000"; d="scan'208";a="18316327" Received: from mail.uj.edu.pl ([149.156.89.147]) by mail1-smtp-roc.national.inria.fr with ESMTP; 06 Oct 2008 19:15:41 +0200 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=UTF-8; format=flowed Received: from [137.73.5.196] by mail.uj.edu.pl (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTPA id <0K8B00J3AULTJ810@mail.uj.edu.pl> for caml-list@yquem.inria.fr; Mon, 06 Oct 2008 19:15:30 +0200 (CEST) Message-id: <48EA47B1.5060003@uj.edu.pl> Date: Mon, 06 Oct 2008 18:15:29 +0100 From: Dawid Toton User-Agent: Thunderbird 1.5.0.12 (X11/20080804) To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] 'Compiler' module References: <1253374D-FC84-4394-99E5-46C02D26C54C@gmail.com> <48E68FD7.7040605@wp.pl> <200810040339.28784.jon@ffconsultancy.com> In-reply-to: <200810040339.28784.jon@ffconsultancy.com> X-Spam: no; 0.00; run-time:01 compilation:01 vastly:01 ocaml:01 python's:01 compiler:01 bytecode:01 runtime:01 monads:01 async:01 translated:01 ocaml:01 async:01 hypothetical:01 compiler:01 > > 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