CODEWITHSUNDEEP
common-lispcompiler-warnings
Student
Student

Reputation: 719

Common Lisp THE gives no compiler warnings

From the examples given for the THE function (http://clhs.lisp.se/Body/s_the.htm) when i change the following form

(the (values integer float) (truncate 3.2 2))

to 

(the (values integer integer) (truncate 3.2 2))

I still don't get any compiler warnings, whereas (the integer 1.2) gives

;Compiler warnings : ; In an anonymous lambda form at position 0: Type declarations violated in (THE INTEGER 1.2)

Can some one explain why the above doesn't produce warnings? I test these on CCL.

Upvotes: 0

Views: 55

Answers (1)

user5920214
user5920214

Reputation:

You have misunderstood what the does. The specification tells you in so many words:

the specifies that the values returned by form are of the types specified by value-type. The consequences are undefined if any result is not of the declared type.

(My emphasis.)

In other words, what the does is to allow you to say to the compiler 'I undertake that these things have these types and you may compile appropriate code for that, with no checks needed; if that's not true then I fully accept that you may need to set my hair on fire and gouge out my one remaining eye'.

Now, famously, CMUCL and its derivatives such as SBCL take a rather different approach to type checking. From the SBCL manual:

The SBCL compiler treats type declarations differently from most other Lisp compilers. Under default compilation policy the compiler doesn’t blindly believe type declarations, but considers them assertions about the program that should be checked: all type declarations that have not been proven to always hold are asserted at runtime.

Thus the system treats the as an assertion about types which, if it is not already known to be true, must be checked. This is, I think, conformant, since 'unspecified consequences' can obviously include 'raising an exception in a nice way' (personally I prefer eye-gouging compilers but that's just me).

But if you want to write portable code, you should not assume that the does this. Rather you need either to accept the risks that it does not, or use some form like check-type or assert with a type check as the thing you are asserting.

Upvotes: 2

Related Questions