[plt-scheme] Is there a general overview of contracts somewhere?
You're right about the usual practice, but I think it's more a matter of
advantage being taken of a loophole than intent as such. As I said in an
earlier response, the CL spec says unequivocally that contexts that violate
a type spec are erroneous; the loophole is that an implementation need not
detect the errors to be conforming. As to the technical matter, after
perusing the doc (MzLib, Chap. 13; DrScheme 209) I'm unsure as to what you
are referring to as "higher-order function contracts". CL type specs do
support specification of function signatures. After quickly reading section
13.2, it appears to me that most of the "->" forms have analogues in CL type
specs, although I'll have to think about the "->r" forms.
BTW, since the CL type system "seamlessly" (it says so right here in the
label :-) integrates CLOS, I believe type specs can be used with methods,
generic functions, and classes.
Thanks, this is interesting,
-- Bill Wood
bill.wood at acm.org
----- Original Message -----
From: "Robby Findler" <robby at cs.uchicago.edu>
To: "jekwtw" <jeaniek7 at comcast.net>
Cc: "Matthias Felleisen" <matthias at ccs.neu.edu>;
<plt-scheme at list.cs.brown.edu>
Sent: Sunday, April 17, 2005 5:45 PM
Subject: Re: [plt-scheme] Is there a general overview of contracts
somewhere?
> At Sun, 17 Apr 2005 16:21:10 -0500, "jekwtw" wrote:
> > Out of curiosity, could you (or someone) provide a brief
> > compare-and-contrast between PLT's contracts and Common Lisp's type
> > specifiers and (declare ...) forms?
>
> I'm not very familiar with Common Lisp's type specs, but from what I
> can tell, there is a substantial philosophical difference in that CL's
> specs are mostly used by the cmpiler to optimize the code generation
> (and thus, might remove checks that would be performed at run-time),
> whereas Mz's are designed to improve the robustness of the code, so are
> always checked, never assumed.
>
> Also, on the technical front, I suspect that higher-order function
> contracts are not supported by CL.
>
> Robby