This is a function of pre-alpha tooling that doesn't do any type analysis. It would be trivial for the compiler to give you a warning in this circumstance with the type information you provided (and production compilers like SBCL will do so).
That is ultimately the point of optional typing. To let you gradually firm up the types in your program as the design gels. The technology is there to get quite a lot of mileage out of the resulting type information, though I think it would definitely behoove Google to make sure the tooling works well from 1.0.
In the declaim I've specified the type of fib to be integer => integer. In the test function, I define a local function that calls a library function to concatenate two constants. The test function then calls fib with the result of calling the local function.
Here, the compiler starts with the known types of "hello" and " world", realizes that the result of CONCATENATE must be an array or null (strings are arrays in Common Lisp), realize that the function FUN always returns a sequence, and then realize that this result conflicts with the asserted type of FIB.
Indeed, if you define FIB inside TEST[1] you don't even need to declare the type of FIB, SBCL figures it out itself.
[1] This restriction is a limitation of the semantics of Common Lisp. Global definitions could be redefined, so SBCL will not flow types through them. Lexical definitions cannot be redefined, so SBCL will analyze them. Dart does not have this limitation.
That is ultimately the point of optional typing. To let you gradually firm up the types in your program as the design gels. The technology is there to get quite a lot of mileage out of the resulting type information, though I think it would definitely behoove Google to make sure the tooling works well from 1.0.
E.g: https://gist.github.com/1325465
In the declaim I've specified the type of fib to be integer => integer. In the test function, I define a local function that calls a library function to concatenate two constants. The test function then calls fib with the result of calling the local function.
Compiling this, SBCL complains: https://gist.github.com/1325469
Here, the compiler starts with the known types of "hello" and " world", realizes that the result of CONCATENATE must be an array or null (strings are arrays in Common Lisp), realize that the function FUN always returns a sequence, and then realize that this result conflicts with the asserted type of FIB.
Indeed, if you define FIB inside TEST[1] you don't even need to declare the type of FIB, SBCL figures it out itself.
[1] This restriction is a limitation of the semantics of Common Lisp. Global definitions could be redefined, so SBCL will not flow types through them. Lexical definitions cannot be redefined, so SBCL will analyze them. Dart does not have this limitation.