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:

http://groups.google.co.uk/group/comp.lang.python/msg/0229d2c6484ea491?hl=en&
http://groups.google.co.uk/group/comp.lang.python/msg/daf7bbb2bd7e99f3?hl=en&

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
http://www.ffconsultancy.com/products/ocaml_for_scientists