[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).
More information about the ecl-devel