On Thu, 2006-12-21 at 16:11 -0500, Serge Aleynikov wrote:
> Chad Perrin wrote:

> What I meant by "strict typing" was performing type checks *at runtime*, 
> i.e. that there are no unsafe operations.
> 
> Say, as an example, doing type checks of function arguments at runtime:
> 
> let f = fun i when is_integer (i) -> i
>            | x when is_float   (x) -> int_of_float x;;
> 
> (raising Bad_match of some sort if neither one of the two guards pass)
> 

Just BTW .. it is very bad to raise exceptions on type errors.
The program should be aborted.

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.

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

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.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net