<div class="gmail_quote">On Mon, Dec 6, 2010 at 10:23 AM, Robby Findler <span dir="ltr"><<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Dec 6, 2010 at 11:19 AM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>> wrote:<br>
><br>
><br>
> On Mon, Dec 6, 2010 at 10:16 AM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>><br>
> wrote:<br>
>><br>
>> Who should be blamed if the coercion does not return a response?<br>
><br>
> The provider of the coercion should be blamed, but that is not possible [I<br>
> think] so the positive party of the whole dynamic/c is blamed.<br>
<br>
</div>Can you show us an example use of this contract from the web server?<br></blockquote><div><br></div><div>The HEAD Web Server has this definition of response/c:</div><div><br></div><div><div>(define response/c</div>
<div> (or/c response/basic?</div><div> (cons/c bytes? (listof (or/c string? bytes?)))</div><div> pretty-xexpr/c))</div></div><div><br></div><div>My local changes have:</div><div><br></div><div><div>(define current-response/c</div>
<div> (make-parameter any/c))</div><div>(define response/c</div><div> (dynamic/c any/c current-response/c response?))</div></div><div><br></div><div>My compatibility library is just a module with this body:</div><div><br>
</div><div>(current-response/c (coerce/c normalize-response))</div><div><br></div><div>where normalize-response is the function (basically) that the old Web Server always used before relying on anything in particular about a response and coerce/c is a trivial thing that turns a coercion into a contract:</div>
<div><br></div><div><div>(define (coerce/c i->o)</div><div> (make-contract</div><div> #:name (build-compound-type-name 'coerce i->o)</div><div> #:projection</div><div> (λ (b)</div><div> (λ (x)</div><div>
(or (i->o x)</div><div> (raise-blame-error b x "Coercion failed"))))))</div></div><div><br></div><div>My local copy will also provide xexpr-response/c:</div><div><br></div><div><div>(define xexpr-response/c</div>
<div> (coerce/c</div><div> (λ (x)</div><div> (cond</div><div> [(response? x)</div><div> x]</div><div> [(xexpr? x)</div><div> (response/xexpr x)]</div><div> [else</div><div> #f]))))</div>
</div><div><br></div><div>which many users will want to use as a current-response/c, although I will not ship any code that uses it exist for test cases.</div><div><br></div><div>Jay</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
>> Is there a contract on current-response/c? (I assume that the "/c"<br>
>> there is a misnomer and it really is a parameter that holds a<br>
>> contact/coercion, not a contract.)<br>
><br>
> current-response/c is contracted with (parameter/c contract?)<br>
> The /c is not a misnomer, you are just parsing it wrong. Read it as<br>
> (parameter (contract response)) not (contract (parameter response)), where<br>
> /c is the post-fix syntax for (contract x) and current- is the pre-fix<br>
> syntax for (parameter x)<br>
<br>
</div>Ah. I see.<br>
<font color="#888888"><br>
Robby<br>
</font><div><div></div><div class="h5"><br>
><br>
>><br>
>> Robby<br>
>><br>
>> On Mon, Dec 6, 2010 at 10:55 AM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>><br>
>> wrote:<br>
>> > Maybe dynamic/c isn't clear enough... its definition is pretty short:<br>
>> > (define (dynamic/c pre parameter post)<br>
>> > (define pre-ctc (coerce-contract 'pre pre))<br>
>> > (define post-ctc (coerce-contract 'post post))<br>
>> > (make-contract<br>
>> > #:name (build-compound-type-name 'dynamic pre-ctc parameter post-ctc)<br>
>> > #:projection<br>
>> > (λ (b)<br>
>> > (define pre-proj ((contract-projection pre-ctc) b))<br>
>> > (define post-proj ((contract-projection post-ctc) b))<br>
>> > (λ (x)<br>
>> > (define dyn-proj<br>
>> > ((contract-projection (coerce-contract 'dynamic (parameter)))<br>
>> > b))<br>
>> > (post-proj<br>
>> > (dyn-proj<br>
>> > (pre-proj<br>
>> > x)))))))<br>
>> > The system provides pre and post, so it can offer protection to the<br>
>> > coercion<br>
>> > as well as receive protection FROM the coercion. But the coercion comes<br>
>> > from<br>
>> > a parameter which is exposed to the user.<br>
>> > The one I use in the web-server is:<br>
>> > (dynamic/c any/c current-response/c response?)<br>
>> > where response? is the data structure predicate that the internal<br>
>> > plumbing<br>
>> > uses.<br>
>> > Jay<br>
>> > On Mon, Dec 6, 2010 at 9:51 AM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> That's why dynamic/c has a pre/c and post/c. Before it uses the user's<br>
>> >> contract, it applies pre/c. After it applies post/c. This ensures that<br>
>> >> the<br>
>> >> user's contract actually coerces to a response?<br>
>> >> Jay<br>
>> >><br>
>> >> On Mon, Dec 6, 2010 at 9:25 AM, Robby Findler<br>
>> >> <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> wrote:<br>
>> >>><br>
>> >>> On Mon, Dec 6, 2010 at 9:23 AM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>> > Yes, since I am allowing users to customize the coercion behavior, I<br>
>> >>> > could<br>
>> >>> > either have them provide two functions: a coercion-applies? function<br>
>> >>> > and a<br>
>> >>> > coercion function; OR I could have them just provide the coercion<br>
>> >>> > function<br>
>> >>> > and I will check the answer and re-run it inside of the function<br>
>> >>> > body.<br>
>> >>> ><br>
>> >>> > The other issue is that finding all the places where I should apply<br>
>> >>> > the<br>
>> >>> > coercion inside the body of the function is difficult, because I<br>
>> >>> > need<br>
>> >>> > to do<br>
>> >>> > it at every place where a response/c could flow in (relatively easy)<br>
>> >>> > and<br>
>> >>> > every place where a response/c could flow out (much hard, esp. with<br>
>> >>> > continuations). Contracts on functions are very nice in their<br>
>> >>> > ability<br>
>> >>> > to do<br>
>> >>> > stuff to inputs and outputs.<br>
>> >>><br>
>> >>><br>
>> >>> I think I need more help to understand the programming problem better.<br>
>> >>> Why are your users supplying you a contract that you are using to<br>
>> >>> protect your functions? That is how can you use anything about that<br>
>> >>> contract to avoid errors in your programs?<br>
>> >>><br>
>> >>> Robby<br>
>> >>><br>
>> >>> > Jay<br>
>> >>> ><br>
>> >>> > On Mon, Dec 6, 2010 at 8:19 AM, Matthias Felleisen<br>
>> >>> > <<a href="mailto:matthias@ccs.neu.edu">matthias@ccs.neu.edu</a>><br>
>> >>> > wrote:<br>
>> >>> >><br>
>> >>> >> The string->number primitive is probably closer to what Jay wants<br>
>> >>> >> to<br>
>> >>> >> do.<br>
>> >>> >><br>
>> >>> >> The only contract I can think of for string->number is<br>
>> >>> >><br>
>> >>> >> ;; Number -> Boolean<br>
>> >>> >> (define (string->number-able? x)<br>
>> >>> >> (number? (string->number x)))<br>
>> >>> >><br>
>> >>> >> So the real problem is a performance problem, which a lazy<br>
>> >>> >> interpretation<br>
>> >>> >> of contracts by the compiler might be able to eliminate.<br>
>> >>> >><br>
>> >>> >> Is this the true problem Jay -- Matthias<br>
>> >>> >><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >> On Dec 6, 2010, at 9:45 AM, Robby Findler wrote:<br>
>> >>> >><br>
>> >>> >> > Let's be clear here: our inability to enforce projectionness is<br>
>> >>> >> > in<br>
>> >>> >> > no<br>
>> >>> >> > way condoning the two coercianlike contracts that you have now<br>
>> >>> >> > written.<br>
>> >>> >> ><br>
>> >>> >> > That said, the only value I see to contracts that only signal<br>
>> >>> >> > errors<br>
>> >>> >> > (or do nothing) is that programmers know what to expect from<br>
>> >>> >> > them.<br>
>> >>> >> > The<br>
>> >>> >> > downsides you mention are well taken, of course.<br>
>> >>> >> ><br>
>> >>> >> > In this specific case, your message seems slightly confused:<br>
>> >>> >> > certainly<br>
>> >>> >> > you should be able to use a contract to ensure that the coercion<br>
>> >>> >> > will<br>
>> >>> >> > always succeed. Let's assume you have done that and now discuss<br>
>> >>> >> > only<br>
>> >>> >> > where the coercing bit of the "contract" goes. Is it in a higher<br>
>> >>> >> > order<br>
>> >>> >> > position? Is it something that describes an interface to your<br>
>> >>> >> > module<br>
>> >>> >> > or can it be considered an internal detail?<br>
>> >>> >> ><br>
>> >>> >> > As a possible guide by analogy, consider the path-string?<br>
>> >>> >> > Predicate.<br>
>> >>> >> > It is the contract on many functions the ultimately is connected<br>
>> >>> >> > to<br>
>> >>> >> > some kind of a coercion somehwere buried inside the racket<br>
>> >>> >> > primitives<br>
>> >>> >> > for dealing with the filesystem. Is that like what you want to<br>
>> >>> >> > do?<br>
>> >>> >> > If<br>
>> >>> >> > so, how would your arguments hold up for that part of our system?<br>
>> >>> >> ><br>
>> >>> >> > Robby<br>
>> >>> >> ><br>
>> >>> >> > On Monday, December 6, 2010, Jay McCarthy<br>
>> >>> >> > <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>><br>
>> >>> >> > wrote:<br>
>> >>> >> >> These contracts are not thrown "at dynamic places". The contract<br>
>> >>> >> >> is<br>
>> >>> >> >> always at the module boundary/etc, but its meaning if affected<br>
>> >>> >> >> by<br>
>> >>> >> >> the<br>
>> >>> >> >> dynamic context of the particular boundary crossing. [1]<br>
>> >>> >> >><br>
>> >>> >> >> I'm been thinking about why I want to use contracts for this<br>
>> >>> >> >> purpose.<br>
>> >>> >> >> The alternative is to put an any/c contract in all the places I<br>
>> >>> >> >> currently have response/c and as the first thing in all those<br>
>> >>> >> >> functions call<br>
>> >>> >> >> current-any->response [or as the last thing on returns] on the<br>
>> >>> >> >> input<br>
>> >>> >> >> argument. I would then have to put a note in all the<br>
>> >>> >> >> documentation<br>
>> >>> >> >> of those<br>
>> >>> >> >> any/c that it doesn't REALLY accept anything, instead in other<br>
>> >>> >> >> accepts<br>
>> >>> >> >> things that the dynamic current-any->response will turn into a<br>
>> >>> >> >> response. If<br>
>> >>> >> >> the coercion failed, then I would have to throw an error, which<br>
>> >>> >> >> be<br>
>> >>> >> >> purely<br>
>> >>> >> >> dynamic with no blame information because it would not be<br>
>> >>> >> >> associated with a<br>
>> >>> >> >> contract boundary.<br>
>> >>> >> >><br>
>> >>> >> >> In contrast, using a contract for this purpose allows me to<br>
>> >>> >> >> centralize<br>
>> >>> >> >> the documentation and behavior of these arguments, get correct<br>
>> >>> >> >> blame on<br>
>> >>> >> >> places where the coercion fails, and abstract the coercion out<br>
>> >>> >> >> of<br>
>> >>> >> >> the code<br>
>> >>> >> >> that is using it into its interface. These are all great wins.<br>
>> >>> >> >><br>
>> >>> >> >> In my opinion, if I did not use contracts, the only elegant<br>
>> >>> >> >> thing<br>
>> >>> >> >> to do<br>
>> >>> >> >> would be to recreate something almost exactly like the contract<br>
>> >>> >> >> system but<br>
>> >>> >> >> called the coercion system. That is absurd to me when contracts<br>
>> >>> >> >> already do<br>
>> >>> >> >> exactly this.<br>
>> >>> >> >><br>
>> >>> >> >> Am I just not clever enough to think of another elegant way?<br>
>> >>> >> >> Why is there so much resistance to using the contract system in<br>
>> >>> >> >> a<br>
>> >>> >> >> perfectly legal way according to its own definition & contracts?<br>
>> >>> >> >> [2] [i.e.<br>
>> >>> >> >> "projection" functions are not forced to be projections by any<br>
>> >>> >> >> means. /<br>
>> >>> >> >> contracts already break eq?/equal?-ness / etc]<br>
>> >>> >> >><br>
>> >>> >> >> Jay<br>
>> >>> >> >> 1. We already have such context-sensitive contracts:<br>
>> >>> >> >><br>
>> >>> >> >><br>
>> >>> >> >><br>
>> >>> >> >> <a href="http://docs.racket-lang.org/xml/index.html#(def._((lib._xml/main..rkt)._permissive/c))" target="_blank">http://docs.racket-lang.org/xml/index.html#(def._((lib._xml/main..rkt)._permissive/c))</a><br>
>> >>> >> >><br>
>> >>> >> >> permissive/c exists to allow DrRacket to embed more snips inside<br>
>> >>> >> >> the<br>
>> >>> >> >> XML boxes, which are otherwise not XML elements.<br>
>> >>> >> >> 2. make-contract's projection keyword has the contract (-> any/c<br>
>> >>> >> >> any/c)<br>
>> >>> >> >><br>
>> >>> >> >> The example of make-contract coerces the procedure by<br>
>> >>> >> >> restricting<br>
>> >>> >> >> how<br>
>> >>> >> >> many arguments rather than checking that when it is given that<br>
>> >>> >> >> number of<br>
>> >>> >> >> arguments it is used properly, etc.<br>
>> >>> >> >><br>
>> >>> >> >> Only flat and chaperone contracts attempt to enforce<br>
>> >>> >> >> projection-ness.<br>
>> >>> >> >> On Sun, Dec 5, 2010 at 9:31 AM, Matthias Felleisen<br>
>> >>> >> >> <<a href="mailto:matthias@ccs.neu.edu">matthias@ccs.neu.edu</a>> wrote:<br>
>> >>> >> >><br>
>> >>> >> >> Jay, coercions aka casts in our world are compound words with -><br>
>> >>> >> >> in<br>
>> >>> >> >> between them. Why do you need a new name?<br>
>> >>> >> >><br>
>> >>> >> >> (There is an inconsistency in their behavior. To wit<br>
>> >>> >> >><br>
>> >>> >> >> Welcome to Racket v5.0.99.4.<br>
>> >>> >> >>> (integer->char 1000000000000000)<br>
>> >>> >> >> integer->char: expects argument of type <exact integer in<br>
>> >>> >> >> [0,#x10FFFF],<br>
>> >>> >> >> not in [#xD800,#xDFFF]>; given 1000000000000000<br>
>> >>> >> >><br>
>> >>> >> >> === context ===<br>
>> >>> >> >> /Users/matthias/plt/collects/racket/private/misc.rkt:78:7<br>
>> >>> >> >>> (string->number "a10")<br>
>> >>> >> >> #f<br>
>> >>> >> >><br>
>> >>> >> >> But that is a historical problem.)<br>
>> >>> >> >><br>
>> >>> >> >> ;; ---<br>
>> >>> >> >><br>
>> >>> >> >> I am also reluctant to throw contracts at dynamic places.<br>
>> >>> >> >> Contract<br>
>> >>> >> >> boundaries should be syntactically distinct, e.g., module<br>
>> >>> >> >> boundaries or<br>
>> >>> >> >> define/contract.<br>
>> >>> >> >><br>
>> >>> >> >> ;; ---<br>
>> >>> >> >><br>
>> >>> >> >> I think you're really just checking an assertion. So perhaps you<br>
>> >>> >> >> want<br>
>> >>> >> >> to go with /a as a suffix.<br>
>> >>> >> >><br>
>> >>> >> >><br>
>> >>> >> >> -- Matthias<br>
>> >>> >> >><br>
>> >>> >> >><br>
>> >>> >> >><br>
>> >>> >> >><br>
>> >>> >> >> --<br>
>> >>> >> >> Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>><br>
>> >>> >> >> Assistant Professor / Brigham Young University<br>
>> >>> >> >> <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
>> >>> >> >><br>
>> >>> >> >> "The glory of God is Intelligence" - D&C 93<br>
>> >>> >> >><br>
>> >>> >> >><br>
>> >>> >><br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> > --<br>
>> >>> > Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>><br>
>> >>> > Assistant Professor / Brigham Young University<br>
>> >>> > <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
>> >>> ><br>
>> >>> > "The glory of God is Intelligence" - D&C 93<br>
>> >>> ><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>><br>
>> >> Assistant Professor / Brigham Young University<br>
>> >> <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
>> >><br>
>> >> "The glory of God is Intelligence" - D&C 93<br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>><br>
>> > Assistant Professor / Brigham Young University<br>
>> > <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
>> ><br>
>> > "The glory of God is Intelligence" - D&C 93<br>
>> ><br>
><br>
><br>
><br>
> --<br>
> Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>><br>
> Assistant Professor / Brigham Young University<br>
> <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
><br>
> "The glory of God is Intelligence" - D&C 93<br>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jay McCarthy <<a href="mailto:jay@cs.byu.edu" target="_blank">jay@cs.byu.edu</a>><br>Assistant Professor / Brigham Young University<br><a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
<br>"The glory of God is Intelligence" - D&C 93<br>