Optional types

[address@hidden]

One problem with this idea of "optional type declarations" is that crossing
from a dynamically-typed world into a declared-type world can be quite
expensive. An example which has bedeviled me before: suppose we write a
function foo that takes a list of strings. Because this function is an exported
part of some module, we declare its type, because we agree with Dan (I do,
actually). Now, in a Lisp setting, we can't control how clients call this
function -- it could, for example, be called like this:
   (foo (list (read) (read)))
or perhaps
   (let ((lis (list (read) (read))))
     (if (read)				; If this item is a true value
         (+ (car lis) (cadr lis))	; the list is a list of ints,
         (foo lis)))			; otw, it's a list of strings.

Are we going to typecheck foo's argument when we enter foo? That could involve
an *arbitrarily large* amount of work -- we have to scan the entire list,
checking each element. It's proportional to the length of the input list.
Oooh, ouch.

Maybe we should *not* typecheck foo's argument on entry to foo. Maybe we
should just let it slide; assume it's the right thing. Presumably foo will
eventually invoke a primitive string operation on the elements of the list,
and we can just let these signal the error. Well...
  1. Maybe these primitives are polymorphic, and will also work on, say, 
     integers as well (e.g., PRINC or DISPLAY). Then our foo function will
     just silently do the wrong thing, never signalling the error.
  2. In any event, we certainly want to find the error *as soon as possible*
     -- at the highest possible call in the call tree. We *don't* want, 
     for example, foo to stuff the car of its argument into a hash table,
     and then, 30 minutes later and thousands of lines of code removed,
     have some other chunk of code pull a value from this hash table and
     signal an error when it tries to use it as a string. That would be 
     *much* harder to track down.

It's a conundrum to me.
    -Olin