All dynamic/c does is apply three contracts in a particular order where one is dynamic.
coerce/c strongly implies that the function is coercion, but its implementation is similar to how the contract system must already use projection functions (ie it cannot confirm that are actually projections; it just applies them and uses the result) The default value of current-response/c is a projection (any/c) The compatibility library does not provide anything with the /c suffix that is a coercion --- it gives normalize-response and automatically sets current-response/c, but doesn't give anything that implies it is a "contract" Thus, the only thing that IMHO should irk you is xexpr-response/c that has the /c suffix and uses coerce/c with an actual coercion. Is that the case? What do you want me to call it? Jay On Sun, Dec 5, 2010 at 6:46 AM, Robby Findler <ro...@eecs.northwestern.edu>wrote: > You've made a contract that isn't a projection, but does a coercion? > > I'd be happier if you instead made your own separate wrappers and > didn't use "/c" and didn't call this a contract. > > Robby > > On Sun, Dec 5, 2010 at 12:29 AM, Jay McCarthy <jay.mccar...@gmail.com> > wrote: > > Giving special consideration to Eli and YC's perspectives, I've come up > with > > the following way out of this problem. > > I found a way to provide a global hook that is tasteful to me. I've > created > > "dynamic/c". Here's a little example: > > Examples: > > (define p (make-parameter any/c)) > > (define c (dynamic/c string? p number?)) > > > (contract c "123" 'pos 'neg) > > pos broke the contract > > (dynamic > > string? > > #<procedure:parameter-procedure> > > number?) > > on eval:5:0; expected <number?>, given: "123" > > > (p (coerce/c string->number)) > > > (contract c "123" 'pos 'neg) > > 123 > > > (contract c "123a" 'pos 'neg) > > pos broke the contract > > (dynamic > > string? > > #<procedure:parameter-procedure> > > number?) > > on eval:8:0; Coercion failed > > The Web Server will define response/c as (dynamic/c any/c > current-response/c > > response?) and provide the current-response/c parameter for > customization. > > The default will be no coercion, but Xexpr conversion will be easily > > accessible. A compatibility library will automatically set > > current-response/c appropriately. > > Attached is the new compatibility README. > > I hope this will satisfy all. > > Jay > > > > -- > > 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 > > > -- 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