Types in Lisp and Scheme

Question

I see now that Racket has types. At first glance it seems to be almost identical to Haskell typing. But is Lisp's CLOS covering some of the space Haskell types cover? Creating a very strict Haskell type and an object in any OO language seems vaguely similar. It's just that I've drunk some of the Haskell kool-aid and I'm totally paranoid that if I go down the Lisp road, I'll be screwed due to dynamic typing.

Answer 1

CL type system is more expressive than the Haskell one, e.g., you can have a type (or (integer 1 10) (integer 20 30)) for a value 1,2,...9,10,20,21,...,30.

However, Lisp compilers does not force their understanding of type safety down your throat, so you can ignore their "notes" - at your own risk.

This means that you can write Haskell in Lisp (so to speak) by declaring all value types and carefully making sure that all the necessary types are inferred, but then it is easier to use Haskell in the first place.

Basically, if you want strong static typing, use Haskell or OCaml, if you want strong dynamic typing, use Lisp. If you want weak static typing, use C, if you want weak dynamic typing, use Perl/Python. Each path has its advantages (and zealots) and disadvantages (and detractors), so you will benefit from learning all of them.

Answer 2

Typed Racket is very different from Haskell. Type systems in Lisp and Scheme, and indeed type systems in traditionally untyped language ecosystems in general, have a fundamental goal that other type systems do not - interoperating with existing untyped code. Typed Racket for example introduced whole new typing rules to accommodate various Racket idioms. Consider this function:

(define (first some-list)
  (if (empty? some-list)
      #f
      (car some-list)))

For non-empty lists, this returns the first element. For empty lists, this returns false. This is common in untyped languages; a typed language would use some wrapper type like Maybe or throw an error in the empty case. If we wanted to add a type to this function, what type should be used? It's not [a] -> a (in Haskell notation), because it can return false. It's also not [a] -> Either a Boolean, because (1) it always returns false in the empty case, not an arbitrary boolean and (2) an Either type would wrap elements in Left and false in Right and require you "unwrap the either" to get to the actual element. Instead, the value returns a true union - theres no wrapping constructors, it simply returns one type in some cases and another type in other cases. In Typed Racket, this is represented with the union type constructor:

(: first (All (A) (-> (Listof A) (U A #f))))
(define (first some-list)
  (if (empty? some-list)
      #f
      (car some-list)))

The type (U A #f) states the function could return either an element of the list or false without any wrapping Either instance. The type checker can infer that some-list is either of type (Pair A (Listof A)) or the empty list, and furthermore it infers that in the two branches of the if statement it is known which of those is the case. The type checker knows that in the (car some-list) expression, the list must have the type (Pair A (Listof A)) because the if condition ensures it. This is called occurrence typing and is designed to ease transition from untyped code to typed code.

The problem is migration. There's a ton of untyped Racket code out there, and Typed Racket can't just force you to abandon all your favorite untyped libraries and spend a month adding types to your codebase if you want to use it. This problem applies whenever your adding types gradually to an existing codebase, see TypeScript and its Any type for a javascript application of these ideas.

A gradual type system must provide tools for dealing with common untyped idioms and interacting with existing untyped code. Using it will be quite painful otherwise, see "Why we're no longer using Core.typed" for a Clojure example.