On 06/25/2012 09:04 PM, Asumu Takikawa wrote:
On 2012-06-25 20:17:33 -0600, Ryan Culpepper wrote:
IIUC from your later message, you've implemented the generics
analogue of object/c (per-instance contract), whereas
prop:dict/contract is closer to class/c (per-type contract). It's a
little fuzzy because prop:dict/contract hacks in per-instance
contracts too in a kind of ad hoc way.
That's a good point. The better analogy might be interface contracts vs.
class/c. With generics, it is easy to control all points that an
instance is created since constructors are just procedures. With
classes, you can't get away with that since the instantiation forms are
macros.
The difference/advantage you might get with a per-type contract for
generics is that you get a more interface-like blame story, as with
interface contracts. Coverage isn't as much of an issue since you can
just contract all constructors.
Unfortunately, it's also not clear how to implement interface-like
contracts for generics. Since the generics forms don't control the
constructors, it's not obvious how to instantiate the blame at the
construction site.
You don't want to blame the construction site; the relevant party is the
implementation site, where the generic interface is associated with
concrete methods within a 'struct' form. See the docs for
'struct-type-property/c' for an example.
Ryan
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
