Re: [racket-dev] Removing Xexpr preference from Web Server
I've just committed the culmination of this thread. I've removed the coercive contracts and replaced them with a global imperative any-response hook that defaults to off but can easily be turned on to support X-exprs or the old behavior of the Web Server. Jay On Fri, Nov 26, 2010 at 5:55 PM, Jay McCarthy jay.mccar...@gmail.comwrote: I would like to remove the implicit preference the Web Server gives to Xexprs and the old esoteric bytes response format. This is backwards incompatible change, but I think it will make the server better in the long run as it will promote other HTML encodings, like the xml and html modules, Eli's new system, SXML, etc. I am interested in your opinion. -- Details -- Everywhere that the server expects a response uses the response/c contract http://pre.racket-lang.org/docs/html/web-server/http.html#(def._((lib._web-server/http/response-structs..rkt)._response/c)) This allows the native HTTP response data structures, Xexprs, and lists that start with bytes (the MIME type) where everything after is a byte string or normal string. [I have no idea where that last thing came from, but it was in the legacy server and I've kept it compatible.] In addition to backwards incompatibility, this could make Web programming a bit more verbose, because you'd have to explicitly call make-xexpr-response to construct the response from the Xexpr. I could ease that a little bit by changing its name to xexpr or something similar. Any ideas on the best way to deal with this? Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Thanks, Jay. Robby On Tuesday, December 7, 2010, Jay McCarthy jay.mccar...@gmail.com wrote: I've just committed the culmination of this thread. I've removed the coercive contracts and replaced them with a global imperative any-response hook that defaults to off but can easily be turned on to support X-exprs or the old behavior of the Web Server. Jay On Fri, Nov 26, 2010 at 5:55 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I would like to remove the implicit preference the Web Server gives to Xexprs and the old esoteric bytes response format. This is backwards incompatible change, but I think it will make the server better in the long run as it will promote other HTML encodings, like the xml and html modules, Eli's new system, SXML, etc. I am interested in your opinion. -- Details -- Everywhere that the server expects a response uses the response/c contract http://pre.racket-lang.org/docs/html/web-server/http.html#(def._((lib._web-server/http/response-structs..rkt)._response/c)) This allows the native HTTP response data structures, Xexprs, and lists that start with bytes (the MIME type) where everything after is a byte string or normal string. [I have no idea where that last thing came from, but it was in the legacy server and I've kept it compatible.] In addition to backwards incompatibility, this could make Web programming a bit more verbose, because you'd have to explicitly call make-xexpr-response to construct the response from the Xexpr. I could ease that a little bit by changing its name to xexpr or something similar. Any ideas on the best way to deal with this? Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Tue, Dec 7, 2010 at 1:17 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I've removed the coercive contracts and replaced them with a global imperative any-response hook that defaults to off but can easily be turned on to support X-exprs or the old behavior of the Web Server. Great! Thanks. yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
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.eduwrote: 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 1000) integer-char: expects argument of type exact integer in [0,#x10], not in [#xD800,#xDFFF]; given 1000 === 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 - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
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 1000) integer-char: expects argument of type exact integer in [0,#x10], not in [#xD800,#xDFFF]; given 1000 === 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 - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
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. Jay On Mon, Dec 6, 2010 at 8:19 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: 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
Re: [racket-dev] Removing Xexpr preference from Web Server
(This is a SE sermon, general but hopefully not opaque as Matthew and Robby think my emails often are: Separating the contract from the functionality of a function/method/etc is a matter of stating the interface clearly and as such a matter of documentation. So use contracts for that purpose. In some cases, however, we just don't know how to write performant contracts and we have to give up for now until compilers and runtime systems are better.) On Dec 6, 2010, at 10:23 AM, Jay McCarthy 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. 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,
Re: [racket-dev] Removing Xexpr preference from Web Server
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
Re: [racket-dev] Removing Xexpr preference from Web Server
At Mon, 6 Dec 2010 10:25:57 -0600, Robby Findler wrote: I think I need more help to understand the programming problem better. Isn't Jay just saying that he needs contract-like things to implement interoperability (among modules that have different representations of XML/HTML)? Ok, maybe he shouldn't call them contracts, but all the contract-like infrastructure is currently called contracts. Is there a way to reuse that infrastructure and not call them contracts? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Mon, Dec 6, 2010 at 10:36 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Mon, 6 Dec 2010 10:25:57 -0600, Robby Findler wrote: I think I need more help to understand the programming problem better. Isn't Jay just saying that he needs contract-like things to implement interoperability (among modules that have different representations of XML/HTML)? Ok, maybe he shouldn't call them contracts, but all the contract-like infrastructure is currently called contracts. Is there a way to reuse that infrastructure and not call them contracts? Sure, just use it. And indeed I said earlier in this thread that it was the name that I objected to (and Matthias has also now said the same thing with an explanation as to why). But this seems to perhaps be developing into something more interesting. Maybe there is something more general than contracts and we should have a contracts+X system that supports that, somehow. (Re-reading my messages I see that the tone of them was not good; sorry about that, Jay.) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
The interoperability comment just hit me. What we might be discovering is basically Jacob's thesis in practice. It isn't so much contracts+X that we're looking at to implement interoperability, but contracts = interop-stuff + blame-mechnism + possibly-more. Jay is trying to reuse the first part of this sum -- for purposes that Jacob's thesis seems to imply: contract-like stuff is good to establish interop invariants. Let's see whether the Lazy-Plain Racket experiment bears this out. -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
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.eduwrote: 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:
Re: [racket-dev] Removing Xexpr preference from Web Server
I believe that this line of discussion is on target. Interoperability is between boundaries. Our contract system is really good at finding and interposing between these boundaries, so it is natural to use it in that way. There is a notion of blame in interoperability too, when the cast fails. Jay On Mon, Dec 6, 2010 at 9:46 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: The interoperability comment just hit me. What we might be discovering is basically Jacob's thesis in practice. It isn't so much contracts+X that we're looking at to implement interoperability, but contracts = interop-stuff + blame-mechnism + possibly-more. Jay is trying to reuse the first part of this sum -- for purposes that Jacob's thesis seems to imply: contract-like stuff is good to establish interop invariants. Let's see whether the Lazy-Plain Racket experiment bears this out. -- Matthias _ 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 - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Right. (My contracts+X comment was a view from underneath comment. I was thinking that the documentation system, for example, might have to change to extract the contract part of these new things and show that to the user since I expect the coercion part to be something that is an internal implementation aspect (but still waiting for some help from Jay on that point).) On Mon, Dec 6, 2010 at 10:46 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: The interoperability comment just hit me. What we might be discovering is basically Jacob's thesis in practice. It isn't so much contracts+X that we're looking at to implement interoperability, but contracts = interop-stuff + blame-mechnism + possibly-more. Jay is trying to reuse the first part of this sum -- for purposes that Jacob's thesis seems to imply: contract-like stuff is good to establish interop invariants. Let's see whether the Lazy-Plain Racket experiment bears this out. -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
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
Re: [racket-dev] Removing Xexpr preference from Web Server
On Dec 6, 2010, at 11:42 AM, Robby Findler wrote: But this seems to perhaps be developing into something more interesting. Maybe there is something more general than contracts and we should have a contracts+X system that supports that, somehow. Every time I discuss contracts with a visiting researcher, the first or second thing they always ask is, What if you coerced to a good value instead of throwing an error?, so I'm not surprised that Jay indeed wants just that. I think he's just found an excellent first use case for it in our own system, and so now we should take a look at supporting such, as you have said above. Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Dec 6, 2010, at 12:08 PM, Carl Eastlund wrote: On Mon, Dec 6, 2010 at 11:58 AM, Stevie Strickland sstri...@ccs.neu.edu wrote: On Dec 6, 2010, at 11:42 AM, Robby Findler wrote: But this seems to perhaps be developing into something more interesting. Maybe there is something more general than contracts and we should have a contracts+X system that supports that, somehow. Every time I discuss contracts with a visiting researcher, the first or second thing they always ask is, What if you coerced to a good value instead of throwing an error?, so I'm not surprised that Jay indeed wants just that. I think he's just found an excellent first use case for it in our own system, and so now we should take a look at supporting such, as you have said above. I'm commenting on the general principle, not Jay's particular case, but to me the main benefit of the contract system is helping uncover bugs and giving good feedback about them. This kind of coercion sounds like it is masking bugs, not uncovering them. It seems directly counter to the purpose of contracts. In reasoning about programs in ACL2, where every input is treated as a good input, I find it harder to reason about the resulting programs, not easier. Personally I would not want to see Racket go down the same road. If we're going to have a coercion system, I would like to see a clear line between the coercion system and the contract system. Muddying the distinction between the two seems like a big potential problem to me. Right, I'm not saying that contracts and coercions should be synonymous in our system. I'm just saying that there are lessons (and subsystems) that we can take from implementing an excellent contract system. If we want, we can apply these lessons to make an excellent coercion system, and perhaps now we _should_ start looking in that direction and see what results. Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
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
Re: [racket-dev] Removing Xexpr preference from Web Server
On Mon, Dec 6, 2010 at 10:16 AM, Robby Findler ro...@eecs.northwestern.eduwrote: Who should be blamed if the coercion does not return a response? 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. 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.) current-response/c is contracted with (parameter/c contract?) 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) Jay 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
Re: [racket-dev] Removing Xexpr preference from Web Server
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.eduwrote: 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
Re: [racket-dev] Removing Xexpr preference from Web Server
On Mon, Dec 6, 2010 at 11:19 AM, Jay McCarthy jay.mccar...@gmail.com wrote: On Mon, Dec 6, 2010 at 10:16 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Who should be blamed if the coercion does not return a response? 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. Can you show us an example use of this contract from the web server? 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.) current-response/c is contracted with (parameter/c contract?) 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) Ah. I see. Robby 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
Re: [racket-dev] Removing Xexpr preference from Web Server
On Mon, Dec 6, 2010 at 9:35 AM, Neil Van Dyke n...@neilvandyke.org wrote: Stevie Strickland wrote at 12/06/2010 11:58 AM: Every time I discuss contracts with a visiting researcher, the first or second thing they always ask is, What if you coerced to a good value instead of throwing an error?, so I'm not surprised that Jay indeed wants just that. I think he's just found an excellent first use case for it in our own system, and so now we should take a look at supporting such, as you have said above. If you're talking about recovery from programming errors, I think that's an interesting and hard problem. (Example: programming error results in a bad value, which is detected; you now know that something is wrong, but you might not know the cause or impact, and perhaps coercing to a believed good value just creates a bigger problem.) Coercion can go wrong when it tries to create good value over zealously, but if applied judiciously it should be the same as input validation, which performs the following: 1. accept inputs in particular formats 2. validate the input's soundness - if fails, reject the input 3. if successful - pass the input through Step # 2 is often done as a conversion step, since if the conversion is successful the value is valid. And if you have converted the values to an internal representation already, it makes sense to simply pass on the internal representation, instead of asking the inner function to do the conversion again explicitly. The key is that there isn't a general coercion mechanism, as you do not want to convert all values into the same representation by tracing all coercible routes. But in limited environment it can save quite a bit of typing and denotes intention clearly like a contract system. The nice thing about the contract system is that it has the support of the runtime to assign blame to the correct party, whereas an input validation's error doesn't tell you who the caller is, so it's harder to track down the offending input. So having the ability to assign error to the correct location provided by the runtime can aid people to develop their own limited scope coercion mechanism. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
11 hours ago, Jay McCarthy wrote: On Mon, Dec 6, 2010 at 10:16 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Who should be blamed if the coercion does not return a response? 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. 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.) current-response/c is contracted with (parameter/c contract?) From a bypasser POV, I see something that involves three contracts combined somehow, where one contract is coming from a parameter that is itself contracted... and my first thought is that I sure hope I won't need to deal with all of that when I want to just use the thing. What's unclear to me is why is all of this necessary in contrast to a (contracted) parameter that holds a coercion function? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Mon, Dec 6, 2010 at 9:32 PM, Eli Barzilay e...@barzilay.org wrote: 11 hours ago, Jay McCarthy wrote: On Mon, Dec 6, 2010 at 10:16 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Who should be blamed if the coercion does not return a response? 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. 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.) current-response/c is contracted with (parameter/c contract?) From a bypasser POV, I see something that involves three contracts combined somehow, where one contract is coming from a parameter that is itself contracted... and my first thought is that I sure hope I won't need to deal with all of that when I want to just use the thing. You'll just touch the parameter. What's unclear to me is why is all of this necessary in contrast to a (contracted) parameter that holds a coercion function? The nice thing about the contract is that it is a centralized place for me to use the coercion from. Otherwise, I have to track down all the places that get contracted as response/c (some are inputs and some are outputs) and run the coercion on them. Then all those places will get any/c contracts and some note about being coerced, which I find inelegant. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
The only response struct that will be left is what response/port was. Jay On Mon, Dec 6, 2010 at 9:38 PM, Eli Barzilay e...@barzilay.org wrote: Two days ago, Jay McCarthy wrote: In that directory is the attached README. Perhaps you wrote about this elsewhere, but what's unclear to me is why `response/port' goes away? I liked the idea of using it as the basic way of communicating reponses back to the server -- without any coercions other than outputting some response. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
10 minutes ago, Jay McCarthy wrote: The only response struct that will be left is what response/port was. Ah, whew. 10 minutes ago, Jay McCarthy wrote: On Mon, Dec 6, 2010 at 9:32 PM, Eli Barzilay e...@barzilay.org wrote: From a bypasser POV, I see something that involves three contracts combined somehow, where one contract is coming from a parameter that is itself contracted... and my first thought is that I sure hope I won't need to deal with all of that when I want to just use the thing. You'll just touch the parameter. Whew^2. (I'll still have some uncomfortable-ness wrt something heavy happenning to make all of this work, but I'll just tell myself that the extra cost is negligible compared to the network overhead anyway...) What's unclear to me is why is all of this necessary in contrast to a (contracted) parameter that holds a coercion function? The nice thing about the contract is that it is a centralized place for me to use the coercion from. Otherwise, I have to track down all the places that get contracted as response/c (some are inputs and some are outputs) and run the coercion on them. Then all those places will get any/c contracts and some note about being coerced, which I find inelegant. So it sounds like the issue is not abusing the contract system in itself, but rather abuse the fact that it touches the points where you'd want to do the conversion, right? If so, I think that I see Robby's original point in not calling the new thing a contract, since it's something that is wired through the contract system but not one. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Sat, Dec 4, 2010 at 10:29 PM, Jay McCarthy jay.mccar...@gmail.comwrote: 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. This looks great! And again thanks for taking the time to go through a vetting process - appreciated. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
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 - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
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.eduwrote: 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 - DC 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 - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Sun, Dec 5, 2010 at 8:00 AM, Jay McCarthy jay.mccar...@gmail.com wrote: 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? It also slightly bothers me that you use it with the other contracts, even though it isn't a contract. (In case it wasn't clear, this is a coding guidelines issue, fwiw.) I don't care what else you call it. Coercion seems like a good word, if you want a suggestion. Robby 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 - DC 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 - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
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 1000) integer-char: expects argument of type exact integer in [0,#x10], not in [#xD800,#xDFFF]; given 1000 === 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
After reading through the README, my vote is for a new web-server2 collection and keep web-server frozen as is except to fix bugs. The compatibility issues simply appear to be much more than an explicit make-xexpr-response call and will most likely cause breakage. This is the type of change that two parallel versions should be kept until it's clear everyone has a chance to migrate (and that can take a long while). I like the migration path from mzscheme to scheme to racket that all are still available and maintained. Except for the mutable pair issue that broke a few libraries, it was quite well managed. Cheers, yc On Fri, Dec 3, 2010 at 10:54 PM, Jay McCarthy jay.mccar...@gmail.comwrote: Here is my current plan: Add web-server/compat/0 directory with, e.g., web-server/compat/0/http/response-structs to hold compatibility bindings to bridge the old http/response-structs and the new http/response-structs In that directory is the attached README. What do you think? Jay _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Sat, Dec 4, 2010 at 5:25 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I think you misunderstand. Every place where there is incompatibility listed in the README is solved by putting a call to response/xexpr rather than returning an Xexpr. The file just lays out all the places where you may need to put those calls. Almost all of those places are internal plumbing places that I don't observe people using in practice [especially the ones which I haven't provided compatible bindings for [except for web-server/insta]] Reading it again I realize that my concern is that I cannot discern what I need to do to keep compatibility from the doc alone and that had me concerned. I probably should have waited to read it again in the morning before sending out an email. Question: what does all the removed binding mean? For example, response/basic, response/incremental, etc are all removed. Are these kept in the compatibility layer and the removed mean that they are removed from the old version? I'm not convinced that a parallel version will be any different than a user staying with an old version or taking the directory from the old version and putting it in the new version. If users stay with an old version because of this wouldn't that defeat the purpose of making a new release? Also I would not expect users to manually copy the old web-server and put it into the new version, because such change means they are shackled to their own customization of the platform, which will break when the platform is yet upgraded again. I think the difference is that those are languages where you want interoperability between ported programs and yet-to-be ported. In contrast, even though you can split a Web app into many servlets and many modules per servlet, I don't observe people using multiple servlets [which would be able to be ported separately]; and if you tried to just port some modules of a many-module servlet, it simply wouldn't work with parallel version because there would be, for example, two incompatible request data structures because they are generative. Having the old language available means users do not have to port the code at all. That's the path to least resistance toward an upgrade. My C code written 10 years ago still compiles on new compilers today without me having to fix anything, and that gives me the confidence as an user that I can upgrade to the latest and greatest version, and I can sell those code to whoever wanting to buy them without any fuss on my part. With regards to web-app, people might not write multiple servlets, but if their app is of any complexity (most web apps I know are complex) they will call many other modules to do the work, and that means they might want to write newer modules with newer version of racket because of a new features are being offered (or a critical bug fix being available). But they likely will want to focus their energy on taking advantage of that new feature, instead of having to fix their servlet because of compatibility. Having said that, I am not saying compatibility can never be broken - just that it always comes at a cost. So the users need to be enticed to an upgrade with promise of better functionality, supported with an upgrade path, and perhaps enforced with a grace period of obsolescence. In this specific case, I am not sure what users will gain with the refactoring. I know what it gains architecturally, but the benefits for users have not been articulated. Cuz again, xexpr is a good default format, and users should have a default format instead of having to always make a response explicitly. It feels like the users have lost a benefit. Thanks Jay for putting this up through a vetting process. Although my opinion appears to differ from yours, I want to ensure you know that I appreciate you doing this, as it shows that you value users' input and put the concern of compatibility high. My perspective comes from an industry user and lib writer, and I harbor the hope that racket can achieve that escape velocity perl/python/etc enjoyed, so I constantly apply industry expectations here, which might not be fair yet, since that might not be a goal of the racket team, but I can hope can't I ;) Anyhow - just my 2 cents as usual. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
YC wrote at 12/04/2010 04:19 AM: After reading through the README, my vote is for a new web-server2 collection and keep web-server frozen as is except to fix bugs. I'm still wondering how many people are actually dependent on Web Server right now. I think that this number might grow exponentially, but might be only a handful of people right now. FWIW, my priorities regarding Web Server backward-compatibility, most important to least important: (1) Keep moving Web Server development forward. (2) Keep/make *new* Web Server development a good experience, including giving good demo. (web-server is a little preferred to web-server2.) (3) Have an idea for how to do backward-compatibility in the future. Maybe this involves PLaneT-like specs of which version of the API is used (which, incidentally, would be useful for #lang racket/base as well). (4) Handle migration somehow for people currently using Web Server. This should not require major changes, but might require them to change their source to point to a compatibility library/language. The others are higher priority. Again, most of my Web work is on architectures predating the Racket Web Server, and I've only done a couple small apps using Web Server (research data-browsing/labeling apps), so I'm mostly unaffected. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
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 - DC 93 README Description: Binary data _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Here is my current plan: Add web-server/compat/0 directory with, e.g., web-server/compat/0/http/response-structs to hold compatibility bindings to bridge the old http/response-structs and the new http/response-structs In that directory is the attached README. What do you think? Jay On Tue, Nov 30, 2010 at 11:14 AM, Eli Barzilay e...@barzilay.org wrote: Three hours ago, Robby Findler wrote: On Tue, Nov 30, 2010 at 8:04 AM, Eli Barzilay e...@barzilay.org wrote: Two hours ago, Robby Findler wrote: On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay e...@barzilay.org wrote: The problem here is that there is no name to change -- it's the implicit coercion of xexpr values to a response. Why can't there be two libraries, one that coerces and one that doesn't? More generally, one that acts the same as the current library and one that is intended for new code? That would require a new `web-server' module, as well as a whole bunch of other modules. I know. Even worse, writing a module using one web server library, and using it in the other won't work, since it's a dynamic property of how the result is getting used. (I think it may be possible to be creative to avoid these things being errors when you mix; but maybe it is better to have an error when you mix; I don't have a strong opinion here but I'd try to make mixing work so people can migrate piecemeal.) [I don't see a way to do that.] As I said before, we have done this with the class system many times. We have done this with other parts of the system as well (not as many times tho). It is not a simple thing. That said, massive backwards incompatibility as Jay is proposing seems wrong. I'll leave this Jay, but I think that there are some important points: * Doing the same for the web server will be much more problematic since there are many interface modules that do the implicit coercion. It looks to me like the only way to do that will be a new toplevel `web-server' collection. * Even in the case of the class system, one of the transitions was going the other way -- renaming the old one (still available as `mzlib/class100') instead of having the new one under a new name. * The fact that this is much more problematic in the web server's case, combined with the fact that the change itself is much more minor (compared to the class system changes), is -- IMO -- a strong indication that a backward-compatible change via a parameter is the right way to go (defaulting to the same as it does now). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 README Description: Binary data _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Saturday, Neil Van Dyke wrote: BTW, SXML and xexprs are a big win for Web development. For one large system in PLT Scheme, the architects have repeatedly mentioned the productivity benefits of SXML for HTML pages as one of the major advantages of using Scheme. They also have problems. The ones I ran into, at least with xexprs: they rely on lots of quasi/quotes etc and it's easy to end up with things like quotenbsp/quote. A related problem is the difference between contexts that expect a single value and contexts that expect a list of values -- with one solution of changing an `unquote' to `unquote-splicing' and the usual problems that this can lead to, or going with the bad spanstuff/span hack. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Eli Barzilay wrote at 11/30/2010 06:36 AM: The ones I ran into, at least with xexprs: they rely on lots of quasi/quotes etc and it's easy to end up with things like quotenbsp/quote. I make errors of not getting my quotes, backquotes, and commas in the right place sometimes, but those errors tend to be discovered quickly. BTW, in SHTML, my old SXML derivative for HTML, one does ( nbsp) instead of xexpr's just nbsp for an entity reference. Perhaps there is a little less risk of confusion. I think there would be even less risk of confusion if DrRacket syntax coloring assumed that the quote and backquote characters always introduced a normal Scheme quote/quasiquote context, and colored the literal parts green. A related problem is the difference between contexts that expect a single value and contexts that expect a list of values -- with one solution of changing an `unquote' to `unquote-splicing' and the usual problems that this can lead to, or going with the bad spanstuff/span hack. I ran into this potential pitfall when I was doing PLT servlets with xexprs. It's not so much an issue in SXML, since (for better or worse) SXML permits unnecessary paren nesting, so you never have to splice. Other solutions/workarounds: * Just be careful, and test. * When I was doing PLT servlets, I just had a naming convention for procs that produced xexprs, so foo-bar-xexpr-elem would get unquote and blort-baz-xexpr-content would get unquote-splicing. * Ideally, I'd want static type checking of my HTML/SXML forms. This might have been some of the attraction of Haskell to Oleg. * My template language doesn't use unquote or unquote-splicing, and instead uses constructs that I think are less error-prone. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Robby Findler wrote: This kind of thing has happened many times for other parts of the system (the class system is a good example). We have generally tried to avoid so much breakage and I think we should here. One technique is to have a new name for the new version (or a new name for the old one if that is more appropriate; that still breaks everything but porting is very easy). The problem here is that there is no name to change -- it's the implicit coercion of xexpr values to a response. Why can't there be two libraries, one that coerces and one that doesn't? More generally, one that acts the same as the current library and one that is intended for new code? Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Two hours ago, Neil Van Dyke wrote: Eli Barzilay wrote at 11/30/2010 06:36 AM: The ones I ran into, at least with xexprs: they rely on lots of quasi/quotes etc and it's easy to end up with things like quotenbsp/quote. I make errors of not getting my quotes, backquotes, and commas in the right place sometimes, but those errors tend to be discovered quickly. (The above errors were all over the old pages for years without being discovered...) A related problem is the difference between contexts that expect a single value and contexts that expect a list of values -- with one solution of changing an `unquote' to `unquote-splicing' and the usual problems that this can lead to, or going with the bad spanstuff/span hack. I ran into this potential pitfall when I was doing PLT servlets with xexprs. It's not so much an issue in SXML, since (for better or worse) SXML permits unnecessary paren nesting, so you never have to splice. Yeah, that was my conclusion too, and `scribble/html' does just that (actually it inherits it from `scribble/text'). BTW, another minor disadvantage with xexprs is that you need a separate rendering pass if you want to have references such as a TOC. The `scribble/html' thing allows promises and thunks which makes it easier to deal with. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Nov 30, 2010, at 9:01 AM, Eli Barzilay wrote: (The above errors were all over the old pages for years without being discovered...) Berkeley would have asked if they are really errors then :-) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Tue, Nov 30, 2010 at 8:04 AM, Eli Barzilay e...@barzilay.org wrote: Two hours ago, Robby Findler wrote: On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay e...@barzilay.org wrote: The problem here is that there is no name to change -- it's the implicit coercion of xexpr values to a response. Why can't there be two libraries, one that coerces and one that doesn't? More generally, one that acts the same as the current library and one that is intended for new code? That would require a new `web-server' module, as well as a whole bunch of other modules. I know. Even worse, writing a module using one web server library, and using it in the other won't work, since it's a dynamic property of how the result is getting used. (I think it may be possible to be creative to avoid these things being errors when you mix; but maybe it is better to have an error when you mix; I don't have a strong opinion here but I'd try to make mixing work so people can migrate piecemeal.) --- As I said before, we have done this with the class system many times. We have done this with other parts of the system as well (not as many times tho). It is not a simple thing. That said, massive backwards incompatibility as Jay is proposing seems wrong. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Nov 30, 2010, at 9:58 AM, Robby Findler wrote: That said, massive backwards incompatibility as Jay is proposing seems wrong. + a lot _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Three hours ago, Robby Findler wrote: On Tue, Nov 30, 2010 at 8:04 AM, Eli Barzilay e...@barzilay.org wrote: Two hours ago, Robby Findler wrote: On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay e...@barzilay.org wrote: The problem here is that there is no name to change -- it's the implicit coercion of xexpr values to a response. Why can't there be two libraries, one that coerces and one that doesn't? More generally, one that acts the same as the current library and one that is intended for new code? That would require a new `web-server' module, as well as a whole bunch of other modules. I know. Even worse, writing a module using one web server library, and using it in the other won't work, since it's a dynamic property of how the result is getting used. (I think it may be possible to be creative to avoid these things being errors when you mix; but maybe it is better to have an error when you mix; I don't have a strong opinion here but I'd try to make mixing work so people can migrate piecemeal.) [I don't see a way to do that.] As I said before, we have done this with the class system many times. We have done this with other parts of the system as well (not as many times tho). It is not a simple thing. That said, massive backwards incompatibility as Jay is proposing seems wrong. I'll leave this Jay, but I think that there are some important points: * Doing the same for the web server will be much more problematic since there are many interface modules that do the implicit coercion. It looks to me like the only way to do that will be a new toplevel `web-server' collection. * Even in the case of the class system, one of the transitions was going the other way -- renaming the old one (still available as `mzlib/class100') instead of having the new one under a new name. * The fact that this is much more problematic in the web server's case, combined with the fact that the change itself is much more minor (compared to the class system changes), is -- IMO -- a strong indication that a backward-compatible change via a parameter is the right way to go (defaulting to the same as it does now). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Going back to a point I'm sure others have made already... Perhaps you guys have a good sense of how many people would be affected by any incompatibilities in this case? Most people use open-output-file and hash tables, so you wanted to migrate all those people gently somehow. A relatively small percentage of people used mutable pairs, at least outside of textbooks, so a harsh migration path was more acceptable there. I assume that the Web Server is somewhere between open-output-file and mutable pairs in popularity. If the tradeoff costs of backward-compatibility work and moving the platform forward expeditiously are unclear, perhaps you could poll the stakeholders. Neil Van Dyke wrote at 11/30/2010 01:11 PM: I don't have any important dependencies on the Web Server right now, but just wanted to add that even small backwards-incompatibilities in PLT/Racket have ruffled feathers of consulting clients of mine in the past. When there are backward-incompats, it's *much* better that they be detected at compile time. Example: renaming the hash table procedures was an annoyance when code wouldn't compile, but the changes to open-output-file and friends to use keyword arguments resulted in much more insidious runtime errors. (BTW, Not using Typed Racket yet. Large code base that has been evolving since PLT 1xx/2xx.) When thinking about how you want people to be alerted to incompats, also remember that not everyone reads the release notes. A few times I've seen a programmer install the latest version of PLT to try, which happens to constitute a jump of several versions, and s/he smoke-tests their code with the new version *before* going and reading the release notes for all the intermediate versions. I think that having the platform inform them of incompatibilities through compile-time error messages or compile-time Java-like deprecation warnings gives more confidence in the platform than errors that occur significantly after time T0 in run-time. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On 28 November 2010 00:31, YC yinso.c...@gmail.com wrote: I agree with Neil that xexpr or sxml are very nice representations of html as well. Given their inherent advantage I think an extensible response mechanism might work better: 1. create hooks to handle different response types 2. let the different package to install the necessary hooks For example - the hook might be called make-response-hook, and in xml package (maybe xml/web-server.ss) can install the hook. Such a hook will allow others to make their own extension as well to manage their own custom response types. Agree! that way the Racket web server seems be able to be widely proliferated, and I can handily make a call to that extension instead of converting back and forth . For example, right now, I have to first convert a list to json object, then to byte string before sending out. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Hi Jay: I have a question as to what you refer as backwards incompatible. Will the old way (bytes response format) be workable since currently my blog server is setup by using some libs from untyped from planet and I'm not sure if this change will have any impact to those libs? Thanks, regardless of that, this change looks great so I don't need to worry about escaping and content insertion. Thank you! Nevo On 27 November 2010 08:55, Jay McCarthy jay.mccar...@gmail.com wrote: I would like to remove the implicit preference the Web Server gives to Xexprs and the old esoteric bytes response format. This is backwards incompatible change, but I think it will make the server better in the long run as it will promote other HTML encodings, like the xml and html modules, Eli's new system, SXML, etc. I am interested in your opinion. -- Details -- Everywhere that the server expects a response uses the response/c contract http://pre.racket-lang.org/docs/html/web-server/http.html#(def._((lib._web-server/http/response-structs..rkt)._response/c)) This allows the native HTTP response data structures, Xexprs, and lists that start with bytes (the MIME type) where everything after is a byte string or normal string. [I have no idea where that last thing came from, but it was in the legacy server and I've kept it compatible.] In addition to backwards incompatibility, this could make Web programming a bit more verbose, because you'd have to explicitly call make-xexpr-response to construct the response from the Xexpr. I could ease that a little bit by changing its name to xexpr or something similar. Any ideas on the best way to deal with this? Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Mon, Nov 29, 2010 at 3:41 AM, Nevo sakur.dea...@gmail.com wrote: Hi Jay: I have a question as to what you refer as backwards incompatible. Most Web applications will become contract violators because they are returning Xexprs directly to send/suspend, etc rather than returning response data structures. I will also be cleaning up the old response data-structures, so even those applications will have a break as well. Jay Will the old way (bytes response format) be workable since currently my blog server is setup by using some libs from untyped from planet and I'm not sure if this change will have any impact to those libs? Thanks, regardless of that, this change looks great so I don't need to worry about escaping and content insertion. Thank you! Nevo On 27 November 2010 08:55, Jay McCarthy jay.mccar...@gmail.com wrote: I would like to remove the implicit preference the Web Server gives to Xexprs and the old esoteric bytes response format. This is backwards incompatible change, but I think it will make the server better in the long run as it will promote other HTML encodings, like the xml and html modules, Eli's new system, SXML, etc. I am interested in your opinion. -- Details -- Everywhere that the server expects a response uses the response/c contract http://pre.racket-lang.org/docs/html/web-server/http.html#(def._((lib._web-server/http/response-structs..rkt)._response/c)) This allows the native HTTP response data structures, Xexprs, and lists that start with bytes (the MIME type) where everything after is a byte string or normal string. [I have no idea where that last thing came from, but it was in the legacy server and I've kept it compatible.] In addition to backwards incompatibility, this could make Web programming a bit more verbose, because you'd have to explicitly call make-xexpr-response to construct the response from the Xexpr. I could ease that a little bit by changing its name to xexpr or something similar. Any ideas on the best way to deal with this? Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 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 - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
This kind of thing has happened many times for other parts of the system (the class system is a good example). We have generally tried to avoid so much breakage and I think we should here. One technique is to have a new name for the new version (or a new name for the old one if that is more appropriate; that still breaks everything but porting is very easy). Robby On Monday, November 29, 2010, Jay McCarthy jay.mccar...@gmail.com wrote: On Mon, Nov 29, 2010 at 3:41 AM, Nevo sakur.dea...@gmail.com wrote: Hi Jay: I have a question as to what you refer as backwards incompatible. Most Web applications will become contract violators because they are returning Xexprs directly to send/suspend, etc rather than returning response data structures. I will also be cleaning up the old response data-structures, so even those applications will have a break as well. Jay Will the old way (bytes response format) be workable since currently my blog server is setup by using some libs from untyped from planet and I'm not sure if this change will have any impact to those libs? Thanks, regardless of that, this change looks great so I don't need to worry about escaping and content insertion. Thank you! Nevo On 27 November 2010 08:55, Jay McCarthy jay.mccar...@gmail.com wrote: I would like to remove the implicit preference the Web Server gives to Xexprs and the old esoteric bytes response format. This is backwards incompatible change, but I think it will make the server better in the long run as it will promote other HTML encodings, like the xml and html modules, Eli's new system, SXML, etc. I am interested in your opinion. -- Details -- Everywhere that the server expects a response uses the response/c contract http://pre.racket-lang.org/docs/html/web-server/http.html#(def._((lib._web-server/http/response-structs..rkt)._response/c)) This allows the native HTTP response data structures, Xexprs, and lists that start with bytes (the MIME type) where everything after is a byte string or normal string. [I have no idea where that last thing came from, but it was in the legacy server and I've kept it compatible.] In addition to backwards incompatibility, this could make Web programming a bit more verbose, because you'd have to explicitly call make-xexpr-response to construct the response from the Xexpr. I could ease that a little bit by changing its name to xexpr or something similar. Any ideas on the best way to deal with this? Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 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 - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Sat, Nov 27, 2010 at 12:55 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I would like to remove the implicit preference the Web Server gives to Xexprs and the old esoteric bytes response format. Seems like a good move to me. If a framework wants to privilege some response type over others it can provide the necessary shortcuts. N. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Sat, Nov 27, 2010 at 4:31 AM, Neil Van Dyke n...@neilvandyke.org wrote: * I'd like to efficiently support SXML, as well as my new union of SXML and xexprs, by writing while traversing the data structure, without introducing an extra copy by first converting to byte string. Perhaps response/c could permit a closure to write the content and perhaps to produce or write the headers, or something similar? (Ideally, this does not require plugging together components using units and signatures; sometimes those tools are indispensable, but they're also cumbersome.) I've just added response/port for this purpose, although it only provides the ability to stream the content, the headers must be produced beforehand. Is that a game breaker? * I'd say that using SXML or xexprs for HTML and XML responses from a Web server is the normal and preferred way to implement most pages. Using these efficiently should be easy for people to do in substantial systems, such as by letting them define their own wrapper procedure or syntax for making a response of their preferred type. Using SXML or xexprs for output should also give good demo in tutorials and pilot apps, so it would be nice if people doing #lang simple-web-server or whatever could have a simple and terse way of saying send an HTML response from this SXML or xexpr, with all the continuation magic, such as using one procedure or syntax name, rather than two to four. BTW, SXML and xexprs are a big win for Web development. For one large system in PLT Scheme, the architects have repeatedly mentioned the productivity benefits of SXML for HTML pages as one of the major advantages of using Scheme. I very much agree; I wonder if the single 'make-xexpr-response' will be too much overhead. Jay -- http://www.neilvandyke.org/ -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Jay McCarthy wrote at 11/27/2010 05:39 AM: I've just added response/port for this purpose, although it only provides the ability to stream the content, the headers must be produced beforehand. Is that a game breaker? Thanks. Sounds good. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Sat, Nov 27, 2010 at 2:39 AM, Jay McCarthy jay.mccar...@gmail.comwrote: I've just added response/port for this purpose, although it only provides the ability to stream the content, the headers must be produced beforehand. Is that a game breaker? Having response/port is great. In the future it would also be great to expose the input output port to the servlet. I very much agree; I wonder if the single 'make-xexpr-response' will be too much overhead. It won't be just a single make-xexpr-response at the entry point, if the idea is to push the construction of the type of responses into the servlet, unless the servlet only deals with a single type of response. On Fri, Nov 26, 2010 at 4:55 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I would like to remove the implicit preference the Web Server gives to Xexprs and the old esoteric bytes response format. This is backwards incompatible change, but I think it will make the server better in the long run as it will promote other HTML encodings, like the xml and html modules, Eli's new system, SXML, etc. I am interested in your opinion. I agree with Neil that xexpr or sxml are very nice representations of html as well. Given their inherent advantage I think an extensible response mechanism might work better: 1. create hooks to handle different response types 2. let the different package to install the necessary hooks For example - the hook might be called make-response-hook, and in xml package (maybe xml/web-server.ss) can install the hook. Such a hook will allow others to make their own extension as well to manage their own custom response types. My 2 cents. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Nov 27, 2010, at 4:31 AM, Neil Van Dyke wrote: this does not require plugging together components using units and signatures; sometimes those tools are indispensable, but they're also cumbersome Have you tried the new ones? They work smoothly for most of the time, almost like modules -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
