typing again

[Luke Gorrie]

"Pierpaolo BERNARDI" <bernardp@REDACTED> writes:

> From: "Bengt Kleberg" <eleberg@REDACTED>
> 
> > > > "I'd love to have a type system that once I've developed 
> > > > my application I can optionally employ to catch possible
> > > > type errors that may exist in my code, 
>  
> > common lisp?
> 
> Type declaration in Common Lisp are only for
> speed, they don't catch type errors.

I don't know what the standard mandates, but in practice Common Lisps
can catch type errors both at compile time and at runtime. 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.

Here is an example program that catches a runtime type error:

  (defvar n 0)
  (proclaim '(type (satisfies evenp) n))

  (format t "~&Setting N to even number")
  (setq n 2)
  (format t "~&Setting N to odd number")
  (setq n 3)

The "proclaim" assigns a type to the variable `n'. The type is
(satisfies evenp), meaning that it includes all values for which the
function `evenp' returns true. You can use any function, aswell as a
vast collection of builtin types.

If you run the program, this happens:

  Setting N to even number
  Setting N to odd number

  Type-error in C::BYTE-TYPE-CHECK-XOP:
     3 is not of type (OR NULL (SATISFIES EVENP))

And you end up in the Lisp debugger, asking you how to continue.

Here's a compile-time example, with a function that tries to use its
argument as both a symbol and a number:

  (defun impossible-list (x)
    (list (symbol-name x)
          (1+ x)))

The compiler says:

  ;;; Compiling defun impossible-list
  In: DEFUN IMPOSSIBLE-LIST
    (1+ X)
  --> + 
  ==>
    X
  Warning: Result is a SYMBOL, not a (VALUES &OPTIONAL NUMBER &REST T).

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

Cheers,
Luke