typing again

Pierpaolo BERNARDI bernardp@REDACTED
Tue Apr 8 01:36:29 CEST 2003

From: "Luke Gorrie" <luke@REDACTED>

> > Type declaration in Common Lisp are only for
> > speed, they don't catch type errors.
> I don't know what the standard mandates, 

according the standard, a type declaration is not an assertion
to be checked (either at compile or run time), but a promise 
from the programmer that that type declaration will hold. 

> but in practice Common Lisps
> can catch type errors both at compile time and at runtime. 

Well, at compile time usually they don't.  At run time they must,
unless you supply type declarations. CMUCL is an exception.

In native-code systems, usually (i.e. in all systems but 
CMUCL) type declarations are simply ignored in 'safe code' 
(code compiled at (safety 3)), and they are trusted blindly in 
code compiled at lower safety.  According to the spec the 
system could also trust type declarations in safe code, but 
luckily no system that I know of does this.

Clisp and Symbolics CL, as a diametrically opposite example, 
completely ignore type declarations. 
These systems are always in safe mode (with some exceptions 
for symbolics).

Both approaches are valid according to the standard.

> CMUCL will
> generate runtime type checks for types you specify, and also do fancy
> type-inferencing with what information it has at compile-time and give
> compiler warnings for type errors it finds.

CMUCL chooses to check declarations, except when at the 
lowest safety level.  This is excellent, but don't count on this 
in other  implementations.

Both your examples compile with no errors or warnings in
acl and lispworks (and clisp, of course).  In all of these
implementations a run-time error is signalled, though.
Just like in Erlang.

If you were accessing an array with an index out of bounds,
a type declaration on the index would not protect you, on the
contrary, it may suppress a check that the compiler would have
put in otherwise.

> It all seems very impressive to me. I haven't done enough CL to know
> if it's actually blissful to work with.

It is.  Just there are a lot of dark corners, and many implementations,
each with its own set of idiosyncrasies.


More information about the erlang-questions mailing list