Yes, the idea is that you can set the parameter inside your servlet and that will effect the thread-cell for your servlet thread. Or, you can parameterize before you serve/servlet or send/suspend for a sub-component of your servlet with a different response representation
Jay On Mon, Dec 6, 2010 at 10:18 AM, Robby Findler <ro...@eecs.northwestern.edu>wrote: > Also: is this really supposed to be a parameter? That is, do you use > parameterize with it? (If so, how does that interact with the ho > stuff?) > > Robby > > On Mon, Dec 6, 2010 at 11:16 AM, Robby Findler > <ro...@eecs.northwestern.edu> wrote: > > Who should be blamed if the coercion does not return a response? > > > > 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.) > > > > Robby > > > > On Mon, Dec 6, 2010 at 10:55 AM, Jay McCarthy <jay.mccar...@gmail.com> > 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 <jay.mccar...@gmail.com> > 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 > >>> <ro...@eecs.northwestern.edu> wrote: > >>>> > >>>> On Mon, Dec 6, 2010 at 9:23 AM, Jay McCarthy <jay.mccar...@gmail.com> > >>>> 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 > >>>> > <matth...@ccs.neu.edu> > >>>> > 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 < > jay.mccar...@gmail.com> > >>>> >> > 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: > >>>> >> >> > >>>> >> >> > >>>> >> >> > http://docs.racket-lang.org/xml/index.html#(def._((lib._xml/main..rkt)._permissive/c)) > >>>> >> >> > >>>> >> >> 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 > >>>> >> >> <matth...@ccs.neu.edu> 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 <j...@cs.byu.edu> > >>>> >> >> Assistant Professor / Brigham Young University > >>>> >> >> http://faculty.cs.byu.edu/~jay > >>>> >> >> > >>>> >> >> "The glory of God is Intelligence" - D&C 93 > >>>> >> >> > >>>> >> >> > >>>> >> > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > Jay McCarthy <j...@cs.byu.edu> > >>>> > Assistant Professor / Brigham Young University > >>>> > http://faculty.cs.byu.edu/~jay > >>>> > > >>>> > "The glory of God is Intelligence" - D&C 93 > >>>> > > >>> > >>> > >>> > >>> -- > >>> Jay McCarthy <j...@cs.byu.edu> > >>> Assistant Professor / Brigham Young University > >>> http://faculty.cs.byu.edu/~jay > >>> > >>> "The glory of God is Intelligence" - D&C 93 > >> > >> > >> > >> -- > >> Jay McCarthy <j...@cs.byu.edu> > >> Assistant Professor / Brigham Young University > >> http://faculty.cs.byu.edu/~jay > >> > >> "The glory of God is Intelligence" - D&C 93 > >> > > > -- Jay McCarthy <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev