10 minutes ago, Jay McCarthy wrote:
> The only response struct that will be left is what response/port
> was.
Ah, whew.
10 minutes ago, Jay McCarthy wrote:
>
>
> On Mon, Dec 6, 2010 at 9:32 PM, Eli Barzilay <e...@barzilay.org> wrote:
>
> 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.
Whew^2. (I'll still have some uncomfortable-ness wrt "something heavy
happenning to make all of this work", but I'll just tell myself that
the extra cost is negligible compared to the network overhead
anyway...)
> 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.
So it sounds like the issue is not abusing the contract system in
itself, but rather abuse the fact that it touches the points where
you'd want to do the conversion, right? If so, I think that I see
Robby's original point in not calling the new thing a "contract",
since it's something that is wired through the contract system but not
one.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
