English version
Accueil     Ŕ propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis ŕ jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml ŕ l'adresse ocaml.org.

Browse thread
Scripting in ocaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-12-22 (15:22)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Scripting in ocaml
On Friday 22 December 2006 02:51, skaller wrote:
> Just BTW .. it is very bad to raise exceptions on type errors.

For what definition of "type"?

> The reason is that raising such exceptions also allows for
> catching them, which means doing a type error is no longer
> unsafe and no longer a bug, but a legitimate technique.
> This in turn defeats most static type analysis you might do.

Absolutely. But the ability to do run-time dispatch based upon type is an 
advantage of dynamic typing, so it is something that you do not want to lose.

> For example this destroys the ability to analyse Python
> statically for the purpose of optimising it.

Yes. An optimising Python compiler will only be adopted/useful if it can 
evaluate any Python. Note that this could mean reverting to interpreted 
bytecode when the program is inherently dynamically typed.

> It is *essential* that the language description not
> mandate raising exceptions on type errors, but rather
> specify the action is undefined .. even if the implementation
> raises an exception, the language specification must NOT
> require that. This prevents programmers actually relying on it
> and allows a static analyser to optimise the code on the
> assumption it is well typed.

You can raise exceptions from unexpectedly typed code whilst keeping the 
advantages of static checking and performance in F#, for example. This gives 
you the advantages of both worlds: performance/reliability when leveraging 
static typing and brevity/generality when leveraging dynamic typing.

For example, I recently benchmarked C++, F#, OCaml and Python for computing 
discrete wavelet transforms. F# (on 32-bit WXP) was slightly faster than 
OCaml (on 64-bit Debian), so it can have very competitive performance:


Yet F# retains run-time type information so you can use a generic print 
function (print_any) on any type, have your dynamic code loading and so on. 
The best of both worlds.

On a related note, F# supports operator overloading, which greatly simplifies 
many mathematical expressions at the cost of requiring more type annotations.

Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists