On Tue, Dec 7, 2010 at 1:17 PM, Jay McCarthy wrote:
>
> I've removed the coercive contracts and replaced them with a global
> imperative any->response hook that defaults to "off" but can easily be
> turned "on" to support X-exprs or the old behavior of the Web Server.
>
Great! Thanks.
yc
__
Thanks, Jay.
Robby
On Tuesday, December 7, 2010, Jay McCarthy wrote:
> I've just committed the culmination of this thread.
> I've removed the coercive contracts and replaced them with a global
> imperative any->response hook that defaults to "off" but can easily be turned
> "on" to support X-e
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
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 wrote:
>
> From a bypasser POV, I see something that involves three
> contrac
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 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 `resp
On Mon, Dec 6, 2010 at 9:32 PM, Eli Barzilay 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 t
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 o
11 hours ago, Jay McCarthy wrote:
>
>
> On Mon, Dec 6, 2010 at 10:16 AM, Robby Findler
> 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
On Mon, Dec 6, 2010 at 9:35 AM, Neil Van Dyke 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 no
Wow - the thread doubled in size overnight ;)
On Mon, Dec 6, 2010 at 9:39 AM, Robby Findler
wrote:
> In other words, this seems like a step backwards from a "do I, as a
> client of the webserver, understand the API of the webserver and can I
> program to it?" perspective.
>
This is why I said th
This is starting to feel more like a clever hack and less like a
useful way to provide support for people wanting to use the web
server. Please correct me if I'm getting this wrong. Here's why I say
that:
One use I see of respnose/c is this:
send/suspend : (-> (-> string response/c) request?)
T
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
On Mon, Dec 6, 2010 at 10:23 AM, Robby Findler
wrote:
> On Mon, Dec 6, 2010 at 11:19 AM, 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?
> >
> >
On Mon, Dec 6, 2010 at 11:19 AM, Jay McCarthy wrote:
>
>
> On Mon, Dec 6, 2010 at 10:16 AM, Robby Findler
> 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 o
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
On Mon, Dec 6, 2010 at 10:16 AM, Robby Findler
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-r
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
wrote:
> Who should be blamed if the coercion does not return a response?
>
> Is there a contract on
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 wrote:
> Maybe
On Dec 6, 2010, at 12:08 PM, Carl Eastlund wrote:
> On Mon, Dec 6, 2010 at 11:58 AM, Stevie Strickland
> 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 contract
On Mon, Dec 6, 2010 at 11:58 AM, Stevie Strickland 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
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
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)
#
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 implem
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
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
wrote:
> On Mon, Dec 6, 2010 at 9:23 AM, Jay McCarth
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
On Mon, Dec 6, 2010 at 10:36 AM, Matthew Flatt 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
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 sho
On Mon, Dec 6, 2010 at 9: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 ch
(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.
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.
Th
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
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 me
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
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 ; given 1000
On Sun, Dec 5, 2010 at 8:00 AM, Jay McCarthy wrote:
> All dynamic/c does is apply three contracts in a particular order where one
> is dynamic.
> coerce/c strongly implies that the function is coercion, but its
> implementation is similar to how the contract system must already use
> projection fu
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; i
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 wrote:
> Giving special consideration to Eli and YC's persp
On Sat, Dec 4, 2010 at 10:29 PM, Jay McCarthy wrote:
>
> The Web Server will define response/c as (dynamic/c any/c
> current-response/c response?) and provide the current-response/c parameter
> for customization. The default will be no coercion, but Xexpr conversion
> will be easily accessible. A
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/
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 exponen
On Sat, Dec 4, 2010 at 5:25 AM, Jay McCarthy wrote:
>
> I think you misunderstand. Every place where there is incompatibility
> listed in the README is solved by putting a call to response/xexpr rather
> than returning an Xexpr. The file just lays out all the places where you may
> need to put th
On Sat, Dec 4, 2010 at 2:19 AM, YC wrote:
> 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 l
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 tha
Here is my current plan:
Add web-server/compat/0 directory with, e.g.,
web-server/compat/0/http/response-structs to hold compatibility bindings to
bridge the old http/response-structs and the new http/response-structs
In that directory is the attached README.
What do you think?
Jay
On Tue, Nov
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
Three hours ago, Robby Findler wrote:
> On Tue, Nov 30, 2010 at 8:04 AM, Eli Barzilay wrote:
> > Two hours ago, Robby Findler wrote:
> >> On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay wrote:
> >> >
> >> > The problem here is that there is no name to change -- it's the
> >> > implicit "coercion" o
I don't have any important dependencies on the Web Server right now, but
just wanted to add that even small backwards-incompatibilities in
PLT/Racket have ruffled feathers of consulting clients of mine in the past.
When there are backward-incompats, it's *much* better that they be
detected at
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
On Tue, Nov 30, 2010 at 8:04 AM, Eli Barzilay wrote:
> Two hours ago, Robby Findler wrote:
>> On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay wrote:
>> >
>> > The problem here is that there is no name to change -- it's the
>> > implicit "coercion" of xexpr values to a response.
>>
>> Why can't ther
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:
ht
Two hours ago, Robby Findler wrote:
> On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay wrote:
> >
> > The problem here is that there is no name to change -- it's the
> > implicit "coercion" of xexpr values to a response.
>
> Why can't there be two libraries, one that coerces and one that
> doesn't?
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
> > "nbsp".
>
> I make errors of not getting my quotes, backquotes, and commas in
> the
On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay wrote:
> Yesterday, Robby Findler wrote:
>> This kind of thing has happened many times for other parts of the
>> system (the class system is a good example). We have generally tried
>> to avoid so much breakage and I think we should here. One technique
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 "nbsp".
I make errors of not getting my quotes, backquotes, and commas in the
right place sometimes, but those errors tend to be
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 problem
Yesterday, Robby Findler wrote:
> This kind of thing has happened many times for other parts of the
> system (the class system is a good example). We have generally tried
> to avoid so much breakage and I think we should here. One technique
> is to have a new name for the new version (or a new name
On Mon, Nov 29, 2010 at 9:36 AM, Jay McCarthy wrote:
> I really dislike such global imperative state, but it should be easy
> to write response/hooks or something to provide this as a library. The
> default response will be a streaming output though, so it will be easy
> to make everything efficie
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 appropr
I really dislike such global imperative state, but it should be easy
to write response/hooks or something to provide this as a library. The
default response will be a streaming output though, so it will be easy
to make everything efficient in extensions.
Jay
On Mon, Nov 29, 2010 at 3:29 AM, Nevo
On Mon, Nov 29, 2010 at 3:41 AM, Nevo wrote:
> Hi Jay:
> I have a question as to what you refer as "backwards incompatible".
Most Web applications will become contract violators because they are
returning Xexprs directly to send/suspend, etc rather than returning
response data structures. I wil
Hah.. Okay, then I will fill the bug reports in time once this change is in.
Thank you!
On 29 November 2010 17:43, Noel Welsh wrote:
> Those libs will be supported in a more or less active manner depending
> on us receiving bug reports and our workload at the time.
>
> N.
>
> On Mon, Nov 29, 201
Those libs will be supported in a more or less active manner depending
on us receiving bug reports and our workload at the time.
N.
On Mon, Nov 29, 2010 at 8:41 AM, Nevo wrote:
> Hi Jay:
> I have a question as to what you refer as "backwards incompatible".
> Will the old way (bytes response
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,
rega
On 28 November 2010 00:31, YC wrote:
>
>
> I agree with Neil that xexpr or sxml are very nice representations of html
> as well. Given their inherent advantage I think an extensible response
> mechanism might work better:
>
>1. create hooks to handle different response types
>2. let the d
Jay McCarthy writes:
> I would like to remove the implicit preference the Web Server gives to
> Xexprs and the old esoteric bytes response format. This is backwards
> incompatible change, but I think it will make the server better in the
> long run as it will promote other HTML encodings, like t
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 modul
On Sat, Nov 27, 2010 at 2:39 AM, Jay McCarthy wrote:
>
> I've just added response/port for this purpose, although it only
> provides the ability to stream the content, the headers must be
> produced beforehand. Is that a game breaker?
Having response/port is great. In the future it would also b
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/
__
On Sat, Nov 27, 2010 at 4:31 AM, Neil Van Dyke wrote:
> * I'd like to efficiently support SXML, as well as my new union of SXML and
> xexprs, by writing while traversing the data structure, without introducing
> an extra copy by first converting to byte string. Perhaps "response/c"
> could permit
* I'd like to efficiently support SXML, as well as my new union of SXML
and xexprs, by writing while traversing the data structure, without
introducing an extra copy by first converting to byte string. Perhaps
"response/c" could permit a closure to write the content and perhaps to
produce or w
On Sat, Nov 27, 2010 at 12:55 AM, Jay McCarthy wrote:
> I would like to remove the implicit preference the Web Server gives to
> Xexprs and the old esoteric bytes response format.
Seems like a good move to me. If a framework wants to privilege some
response type over others it can provide the nec
I would like to remove the implicit preference the Web Server gives to
Xexprs and the old esoteric bytes response format. This is backwards
incompatible change, but I think it will make the server better in the
long run as it will promote other HTML encodings, like the xml and
html modules, Eli's n
73 matches
Mail list logo
