[racket-dev] Win64
Racket now supports 64-bit Windows (Vista and up). To build for 64-bit Windows using VS 2008: 1. Use vcvarsall x64 to configure your environment for a 64-bit build, where vcvarsall.bat is supplied by Visual Studio in the VC subdirectory. 2. Run build.bat in racket\src\worksp. _ 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
[racket-dev] Hacking on the collects
I added support for secure websockets to net/websocket/client and now I am wondering how I should make such changes in th future to easily integrate them back into racket? What I have tried: 1. Fork racket on github 2. Make a local copy 3. Compile everything fro scratch 4. Wait and awful lot of time 4. Change the file in collects 5. Run make install 6. Wait another awful lot of time for raco setup to recomplie everything 7. Test the changes 8. I was planning to create a pull request on github Is there a easier/faster way? Or should I just develop in the live collects tree and then endure the raco setup once for final testing? Thanks for any suggestions. -- regards, Jakub Piotr Cłapa _ 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] Hacking on the collects
On Mon, Dec 6, 2010 at 12:04 PM, Jakub Piotr Cłapa jpc...@zenburn.net wrote: I added support for secure websockets to net/websocket/client and now I am wondering how I should make such changes in th future to easily integrate them back into racket? What I have tried: 1. Fork racket on github 2. Make a local copy 3. Compile everything fro scratch 4. Wait and awful lot of time 4. Change the file in collects 5. Run make install 6. Wait another awful lot of time for raco setup to recomplie everything 7. Test the changes 8. I was planning to create a pull request on github Is there a easier/faster way? Or should I just develop in the live collects tree and then endure the raco setup once for final testing? Here are two things that I do: (a) hack on the live collects (b) just rerun 'raco setup' on the relevant collections (it takes collection arguments on the command line) (c) use the -D argument to 'setup' to skip rebuilding the documentation (d) sometime, I don't rerun 'raco setup' at all, I just rely on running from source. This is slower to run, but avoid the setup time. Of course, you should run setup on the whole tree before requesting a pull or submitting a patch, but skipping the intermediate slowness helps a lot. -- sam th sa...@ccs.neu.edu _ 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] Hacking on the collects
On Mon, Dec 6, 2010 at 12:16 PM, Jay McCarthy jay.mccar...@gmail.com wrote: If you do a pull request on github, it will not be useful because github is a mirror and I'll just need to get the patch some other way anyways. I'd rather you sent the patch directly to me. This isn't quite right. As Eli explained (I think on this list), it's easy to merge from a separate github repository. I find it easier than fiddling with the git patch management commands. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
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] Hacking on the collects
I've done it and it wasn't as nice as getting a patch. Jay On Mon, Dec 6, 2010 at 10:19 AM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote: On Mon, Dec 6, 2010 at 12:16 PM, Jay McCarthy jay.mccar...@gmail.com wrote: If you do a pull request on github, it will not be useful because github is a mirror and I'll just need to get the patch some other way anyways. I'd rather you sent the patch directly to me. This isn't quite right. As Eli explained (I think on this list), it's easy to merge from a separate github repository. I find it easier than fiddling with the git patch management commands. -- sam th sa...@ccs.neu.edu -- 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 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
[racket-dev] Commit logs
Gneral request: can people please use some descriptive commit messages for the logs? A message that has only closes PR 12345 is not very useful (and will likely be even less convenient in the future if/when we move to a different bug tracking system). Also, I'd prefer to not see leftovers from some other system, like the HG hashes -- since they're not useful for others. (I even had doubts about keeping the svn revision information in...) -- ((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
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] Hacking on the collects
On 06.12.10 18:16, Jay McCarthy wrote: I develop in the same git clone that I use. If I change collect X, I test after running raco setup X and once I'm satisfied. I run raco setup to see if other things were affected. I then run tests on things other than X that I know depend on it. Then I push. Does that require symlinking the collects from the git repo to the installation folder or it just means that you do not run make install at all? If you do a pull request on github, it will not be useful because github is a mirror and I'll just need to get the patch some other way anyways. I'd rather you sent the patch directly to me. [Because the websockets stuff is code I maintain.] Ok. I already did the pull request [1] but I have no problem with sending a patch. Btw. I guess that to make a good patch I should try to update the documentation as well? [1]: https://github.com/plt/racket/pull/3 Direct link to the diff: https://github.com/jpc/racket/commit/45441054bc0dbd8ad6fc05f2ae2eb135830a9b02 -- regards, Jakub Piotr Cłapa _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Hacking on the collects
7 minutes ago, Jakub Piotr Cłapa wrote: On 06.12.10 18:16, Jay McCarthy wrote: I develop in the same git clone that I use. If I change collect X, I test after running raco setup X and once I'm satisfied. I run raco setup to see if other things were affected. I then run tests on things other than X that I know depend on it. Then I push. Does that require symlinking the collects from the git repo to the installation folder or it just means that you do not run make install at all? You can just run a build in the working directory. If you do a pull request on github, it will not be useful because github is a mirror and I'll just need to get the patch some other way anyways. I'd rather you sent the patch directly to me. [Because the websockets stuff is code I maintain.] Ok. I already did the pull request [1] but I have no problem with sending a patch. Btw. I guess that to make a good patch I should try to update the documentation as well? Yes -- and tests too. -- ((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
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
