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=AWL autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id D9714BC0A for ; Sat, 23 Dec 2006 19:52:30 +0100 (CET) Received: from ptb-relay02.plus.net (ptb-relay02.plus.net [212.159.14.213]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id kBNIqSdL000359 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 23 Dec 2006 19:52:30 +0100 Received: from [80.229.56.224] (helo=[10.0.0.5]) by ptb-relay02.plus.net with esmtp (Exim) id 1GyByp-0007qu-B0 for caml-list@yquem.inria.fr; Sat, 23 Dec 2006 18:52:23 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Scripting in ocaml Date: Sat, 23 Dec 2006 18:50:04 +0000 User-Agent: KMail/1.9.5 References: <6dbd4d000612201941wcd4b09anc503a13889576512@mail.gmail.com> <1166709162.5653.11.camel@rosella.wigram> <458AA143.3090303@hq.idt.net> In-Reply-To: <458AA143.3090303@hq.idt.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612231850.04578.jon@ffconsultancy.com> X-Miltered: at discorde with ID 458D7AEC.003 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 ocaml:01 intentional:01 unrolling:01 ocaml's:01 run-time:01 erlang:01 run-time:01 compilation:01 checker:01 reloading:01 computations:01 marshalling:01 optimise:01 frog:98 On Thursday 21 December 2006 14:59, Serge Aleynikov wrote: > OCaml has static typing but doesn't provide an actual location of code > in exceptions. Is it because it was hard or intentional? F# uses .NET exceptions. They do provide such information but they are so slow that you must painstakingly avoid any use of exceptions in performance critical code, boxing and unrolling manually if necessary. This is in stark contrast to OCaml's lightning fast exceptions that are used as the basis of optimisations. > > I guess the arguments for static typing and scalability are > > well known. So the reasoning part is clear: we infer larger > > programs without dynamic typing are harder to get right. > > I agree with your statements applicable to imperative/OO dynamicly typed > languages. However if a dynamic language is functional, this makes it > possible to provide run-time static analysis to identify type related > bugs and unreachable code. An example of this is the Dyalizer tool for > Erlang. What do you mean by "run-time static analysis"? Surely if something is analysed at run-time then it cannot be static by definition? > In this case running such a tool after compilation reveals the same > problems that a compile-level static checker would do, but allows for > run-time code reloading, more safe term serialization/deserialization, > and safer cross-language integration. Needless to say, this benefits > comes at price of efficiency, but there are many cases when these > features out-weight a reasonable performance loss that can be regained > by parallelizing computations. Then it might be worthwhile for F#, which supports concurrency. > > Sorry, I wasn't clear. I meant to refer to dynamic loading in Ocaml, > > not in general. Exactly why that is I don't know. Perhaps the > > interaction of the static typing and dynamic loading is not > > easy because it is not well understood how to make it so, > > in Ocaml, and perhaps in general (without losing type safety) > > I believe that introducing strict typing in the language might help in > bridging static typing and dynamic loading. Strict typing would allow > to do run-time type verification and type-specific guard checks. > Though, this would no longer be Ocaml as we know it today. ;-) You could add run-time type information to OCaml and check it at boundaries, like marshalling. However, you'd want to optimise it away whenever possible, if not for performance reasons then to conserve memory. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists