On Mon, Dec 6, 2010 at 9:32 PM, Eli Barzilay <e...@barzilay.org> wrote:
> 11 hours ago, Jay McCarthy wrote: > > > > > > On Mon, Dec 6, 2010 at 10:16 AM, Robby Findler < > ro...@eecs.northwestern.edu> > > wrote: > > > > Who should be blamed if the coercion does not return a response? > > > > > > The provider of the coercion should be blamed, but that is not possible > [I > > think] so the positive party of the whole dynamic/c is blamed. > > > > > > Is there a contract on current-response/c? (I assume that the "/c" > > there is a misnomer and it really is a parameter that holds a > > contact/coercion, not a contract.) > > > > > > current-response/c is contracted with (parameter/c contract?) > > From a bypasser POV, I see something that involves three contracts > combined somehow, where one contract is coming from a parameter that > is itself contracted... and my first thought is that I sure hope I > won't need to deal with all of that when I want to just use the thing. > You'll just touch the parameter. > > What's unclear to me is why is all of this necessary in contrast to a > (contracted) parameter that holds a coercion function? > The nice thing about the contract is that it is a centralized place for me to use the coercion from. Otherwise, I have to track down all the places that get contracted as response/c (some are inputs and some are outputs) and run the coercion on them. Then all those places will get any/c contracts and some note about being coerced, which I find inelegant. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > -- Jay McCarthy <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev