Maybe dynamic/c isn't clear enough... its definition is pretty short:<div><br></div><div><div>(define (dynamic/c pre parameter post)</div><div> (define pre-ctc (coerce-contract 'pre pre))</div><div> (define post-ctc (coerce-contract 'post post))</div> <div> (make-contract</div><div> #:name (build-compound-type-name 'dynamic pre-ctc parameter post-ctc)</div><div> #:projection</div><div> (λ (b)</div><div> (define pre-proj ((contract-projection pre-ctc) b))</div> <div> (define post-proj ((contract-projection post-ctc) b))</div><div> (λ (x)</div><div> (define dyn-proj</div><div> ((contract-projection (coerce-contract 'dynamic (parameter))) b))</div><div> (post-proj </div> <div> (dyn-proj</div><div> (pre-proj</div><div> x)))))))</div><div><br></div><div>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.</div> <div><br></div><div>The one I use in the web-server is:</div><div><br></div><div>(dynamic/c any/c current-response/c response?)</div><div><br></div><div>where response? is the data structure predicate that the internal plumbing uses.</div> <div><br></div><div>Jay</div><br><div class="gmail_quote">On Mon, Dec 6, 2010 at 9:51 AM, Jay McCarthy <span dir="ltr"><<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 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?<div><br></div><div> <font color="#888888"> Jay</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Mon, Dec 6, 2010 at 9:25 AM, Robby Findler <span dir="ltr"><<a href="mailto:robby@eecs.northwestern.edu" target="_blank">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>On Mon, Dec 6, 2010 at 9:23 AM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com" target="_blank">jay.mccarthy@gmail.com</a>> wrote:<br> > Yes, since I am allowing users to customize the coercion behavior, I could<br> > either have them provide two functions: a coercion-applies? function and a<br> > coercion function; OR I could have them just provide the coercion function<br> > and I will check the answer and re-run it inside of the function body.<br> ><br> > The other issue is that finding all the places where I should apply the<br> > coercion inside the body of the function is difficult, because I need to do<br> > it at every place where a response/c could flow in (relatively easy) 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 ability to do<br> > stuff to inputs and outputs.<br> <br> <br> </div>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> <font color="#888888"><br> Robby<br> </font><div><div></div><div><br> > Jay<br> ><br> > On Mon, Dec 6, 2010 at 8:19 AM, Matthias Felleisen <<a href="mailto:matthias@ccs.neu.edu" target="_blank">matthias@ccs.neu.edu</a>><br> > wrote:<br> >><br> >> The string->number primitive is probably closer to what Jay wants to 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 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 in 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 errors<br> >> > (or do nothing) is that programmers know what to expect from them. The<br> >> > downsides you mention are well taken, of course.<br> >> ><br> >> > In this specific case, your message seems slightly confused: certainly<br> >> > you should be able to use a contract to ensure that the coercion will<br> >> > always succeed. Let's assume you have done that and now discuss only<br> >> > where the coercing bit of the "contract" goes. Is it in a higher order<br> >> > position? Is it something that describes an interface to your module<br> >> > or can it be considered an internal detail?<br> >> ><br> >> > As a possible guide by analogy, consider the path-string? Predicate.<br> >> > It is the contract on many functions the ultimately is connected to<br> >> > some kind of a coercion somehwere buried inside the racket primitives<br> >> > for dealing with the filesystem. Is that like what you want to do? 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 <<a href="mailto:jay.mccarthy@gmail.com" target="_blank">jay.mccarthy@gmail.com</a>><br> >> > wrote:<br> >> >> These contracts are not thrown "at dynamic places". The contract is<br> >> >> always at the module boundary/etc, but its meaning if affected by 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 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 functions call<br> >> >> current-any->response [or as the last thing on returns] on the input<br> >> >> argument. I would then have to put a note in all the documentation of those<br> >> >> any/c that it doesn't REALLY accept anything, instead in other accepts<br> >> >> things that the dynamic current-any->response will turn into a response. If<br> >> >> the coercion failed, then I would have to throw an error, which be purely<br> >> >> dynamic with no blame information because it would not be associated with a<br> >> >> contract boundary.<br> >> >><br> >> >> In contrast, using a contract for this purpose allows me to centralize<br> >> >> the documentation and behavior of these arguments, get correct blame on<br> >> >> places where the coercion fails, and abstract the coercion out of 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 thing to do<br> >> >> would be to recreate something almost exactly like the contract system but<br> >> >> called the coercion system. That is absurd to me when contracts 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 a<br> >> >> perfectly legal way according to its own definition & contracts? [2] [i.e.<br> >> >> "projection" functions are not forced to be projections by any means. /<br> >> >> contracts already break eq?/equal?-ness / etc]<br> >> >><br> >> >> Jay<br> >> >> 1. We already have such context-sensitive contracts:<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 the<br> >> >> XML boxes, which are otherwise not XML elements.<br> >> >> 2. make-contract's projection keyword has the contract (-> any/c any/c)<br> >> >><br> >> >> The example of make-contract coerces the procedure by restricting how<br> >> >> many arguments rather than checking that when it is given that number of<br> >> >> arguments it is used properly, etc.<br> >> >><br> >> >> Only flat and chaperone contracts attempt to enforce projection-ness.<br> >> >> On Sun, Dec 5, 2010 at 9:31 AM, Matthias Felleisen<br> >> >> <<a href="mailto:matthias@ccs.neu.edu" target="_blank">matthias@ccs.neu.edu</a>> wrote:<br> >> >><br> >> >> Jay, coercions aka casts in our world are compound words with -> 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 [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. Contract<br> >> >> boundaries should be syntactically distinct, e.g., module boundaries or<br> >> >> define/contract.<br> >> >><br> >> >> ;; ---<br> >> >><br> >> >> I think you're really just checking an assertion. So perhaps you 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" 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> >> >><br> >> >><br> >><br> ><br> ><br> ><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> ><br> </div></div></blockquote></div><br><br clear="all"><br></div></div>-- <br><div class="im">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> </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> </div>