On 2016-01-28 01:54:44 -0500, Scott Moore wrote: > While I could imagine implementing a mechanism that turned the server > obligations of the bound into the corresponding client obligations, I think > it would would have to be hard-coded to particular types of contracts. I > personally would probably lean to accepting this as a practical deviation > from the “right thing,” similar to dynamic casts in most OO languages.
I agree that this may be a practical choice, particularly from the perspective of a (untyped) Racket programmer. My example mainly comes from my bias as a Typed Racket dev. If TR had more support for generics/ad-hoc polymorphism and also had bounded polymorphism it would be important to treat the bound more opaquely. Even function contracts would be an issue if TR let prop:procedure based structs be subtypes of the corresponding function type. (right now TR lets you call such structs as functions but does not encode the subtype relationship) Cheers, Asumu -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/20160129025925.GH15583%40simplyrobot.org. For more options, visit https://groups.google.com/d/optout.
