[Ecls-list] Status of CVS

Gabriel Dos Reis gdr at integrable-solutions.net
Tue May 13 11:04:09 UTC 2008

On Tue, May 13, 2008 at 4:11 AM, Juan Jose Garcia-Ripoll
<jjgarcia at users.sourceforge.net> wrote:
> On Tue, May 13, 2008 at 10:44 AM, Tobias C. Rittweiler <tcr at freebits.de> wrote:
>  >  There _is_ a difference between using declarations-as-assertions and
>  >  using explicit CHECK-TYPE forms: type propagation.
>  >
>  >   (defun foo1 (s)
>  >     (declare (type symbol x))
>  >     (frob s))
>  >
>  >   (defun foo2 (s)
>  >     (check-type s symbol)
>  >     (frob s))
>  >
>  >  A compiler can safely assume that FOO1's parameter has the type SYMBOL,
>  >  while it must resort to give FOO2's parameter the type T. Assuming that
>  >  type violations will be checked for statically, the first way is
>  >  obviously superior, especially during development.
>  Actually, this is not what I have seen routinely. In the first case,
>  the user is _free_ to pass a wrong value to that function.
>  Consequences are completely unspecified. You may get an error, you may
>  get a segmentation fault, etc. This is what I experience with the
>  functions in the pretty printer when subject to the error checking
>  routines in Paul Dietz.
>  My feeling is that there are two lines of thought: that type
>  declarations are not binding, or that they are, and this strongly
>  depends on the behavior of the compiler.
>  However, check-type is way superior in that it will always enforce the
>  type. The compiler can assume that _after_ the call to check-type, the
>  type of the variable "s" will be the expected one. Indeed, this is one
>  of the optimizations I have in mind.

So, what is your take on function type proclamation?
(OpenAxiom uses it a lot).

-- Gaby

More information about the ecl-devel mailing list