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