Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-07 Thread Jay McCarthy
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,

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-07 Thread Robby Findler
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-07 Thread YC
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!

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Jay McCarthy
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Robby Findler
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Jay McCarthy
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.

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Matthias Felleisen
(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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Robby Findler
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Matthew Flatt
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Robby Findler
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Matthias Felleisen
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Jay McCarthy
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,

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Jay McCarthy
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Robby Findler
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Jay McCarthy
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)

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Stevie Strickland
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Stevie Strickland
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Robby Findler
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?

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Jay McCarthy
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Jay McCarthy
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Robby Findler
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread YC
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Eli Barzilay
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Jay McCarthy
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Jay McCarthy
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-06 Thread Eli Barzilay
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-05 Thread YC
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-05 Thread Robby Findler
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-05 Thread Jay McCarthy
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;

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-05 Thread Robby Findler
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-05 Thread Matthias Felleisen
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],

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-04 Thread YC
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-04 Thread YC
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-04 Thread Neil Van Dyke
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-04 Thread Jay McCarthy
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-12-03 Thread Jay McCarthy
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,

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-30 Thread Eli Barzilay
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.

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-30 Thread Neil Van Dyke
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-30 Thread Robby Findler
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.

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-30 Thread Eli Barzilay
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-30 Thread Matthias Felleisen
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:

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-30 Thread Robby Findler
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.

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-30 Thread Matthias Felleisen
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

2010-11-30 Thread Eli Barzilay
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-30 Thread Neil Van Dyke
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-29 Thread Nevo
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-29 Thread Nevo
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,

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-29 Thread Jay McCarthy
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-29 Thread Robby Findler
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-27 Thread Noel Welsh
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-27 Thread Jay McCarthy
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-27 Thread Neil Van Dyke
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/

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-27 Thread YC
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

Re: [racket-dev] Removing Xexpr preference from Web Server

2010-11-27 Thread Matthias Felleisen
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