[racket-dev] Removing Xexpr preference from Web Server

On Mon, Dec 6, 2010 at 9:32 PM, Eli Barzilay <eli at barzilay.org> wrote:

> 11 hours ago, Jay McCarthy wrote:
> >
> >
> > On Mon, Dec 6, 2010 at 10:16 AM, Robby Findler <
> robby at 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 <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20101206/6fe0eb14/attachment.html>