On Wed, Oct 29, 2014 at 6:57 PM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > properly -> corresponding fashion?
No, it's a different change (the one I numbered 1. in my first message). Sam > > Otherwise fine > > > On Oct 29, 2014, at 6:54 PM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote: > >> On Wed, Oct 29, 2014 at 6:42 PM, Matthias Felleisen >> <matth...@ccs.neu.edu> wrote: >>> >>> 1. Can we please, pretty please, drop these "now"s from every single >>> sentence? >>> >>> 2. I think this is close to what we may wish to say. Here is a small edit: >>> >>> * Typed Racket closes a safety hole due to the types for the >>> exception system. The revised type system restricts raise so >>> that only instances of the exn structure type and flat data >>> are communicated to handlers. >> >> I like this, but we need to at least mention the other change. So how about: >> >> * Typed Racket closes two safety holes in the types for the >> exception system. The revised type system restricts raise so >> that only instances of the exn structure type and flat data >> are communicated to handlers, and checks exception handlers properly. >> >> Sam >> >>> >>> 3. I think it is perfectly acceptable to imply that a >>> restriction of an existing type system breaks existing >>> programs. If you don't, I'd say >>> >>> Existing programs may suffer from new type errors >>> due to this restriction. >>> >>> >>> >>> >>> >>> >>> >>> On Oct 29, 2014, at 6:32 PM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> >>> wrote: >>> >>>> Here's another idea: >>>> >>>> * To ensure safety, Typed Racket now prohibits raising any values >>>> other than exns and simple flat data. Some existing programs may now >>>> have type errors because of this. >>>> >>>> Sam >>>> >>>> On Wed, Oct 29, 2014 at 6:12 PM, Sam Tobin-Hochstadt >>>> <sa...@cs.indiana.edu> wrote: >>>>> The reason I don't like the second sentence you wrote is that it's >>>>> true of every type system everywhere. And also, the more significant >>>>> change for users will almost certainly be the first one (it's required >>>>> changes to several packages already) -- almost no one raises anything >>>>> that isn't an exn, and so I haven't seen any code actually affected by >>>>> the second change. >>>>> >>>>> Sam >>>>> >>>>> On Wed, Oct 29, 2014 at 6:00 PM, Robby Findler >>>>> <ro...@eecs.northwestern.edu> wrote: >>>>>> I prefer the second sentence I sent to either of those. Fundamentally >>>>>> I think it is reasonable for the sentence to be slightly apologetic. >>>>>> There was a problem, we fixed it, but the fix may require some pain of >>>>>> our users. There's nothing wrong with that; it's just a fact of life. >>>>>> No shame in hiding it. >>>>>> >>>>>> Robby >>>>>> >>>>>> On Wed, Oct 29, 2014 at 4:55 PM, Sam Tobin-Hochstadt >>>>>> <sa...@cs.indiana.edu> wrote: >>>>>>> On Wed, Oct 29, 2014 at 5:47 PM, Robby Findler >>>>>>> <ro...@eecs.northwestern.edu> wrote: >>>>>>>> Yes, that's what I mean. I don't think that the sentence "This may >>>>>>>> break existing programs that rely on unsafe behavior." is accurate. >>>>>>>> How about "This may break existing programs." or "Closing this hole >>>>>>>> requires us to disallow some programs that do not signal runtime >>>>>>>> errors." or something like that? >>>>>>> >>>>>>> How about "This may result in type errors in existing programs that >>>>>>> rely on the original behavior; specifically, programs that `raise` >>>>>>> higher-order values." >>>>>>> >>>>>>> Sam >>>>>>> >>>>>>>> >>>>>>>> Robby >>>>>>>> >>>>>>>> On Wed, Oct 29, 2014 at 4:35 PM, Sam Tobin-Hochstadt >>>>>>>> <sa...@cs.indiana.edu> wrote: >>>>>>>>> There were two holes. >>>>>>>>> >>>>>>>>> 1. We allowed exception handlers to assume that they received values >>>>>>>>> of type `exn`, even when that wasn't right. >>>>>>>>> 2. We allowed typed programs to throw arbitrary values, which means >>>>>>>>> that you could throw a typed function to an untyped handler, which >>>>>>>>> could then misuse it. >>>>>>>>> >>>>>>>>> Both of these changes could lead to type errors in programs that won't >>>>>>>>> fail at runtime, but that's true of just about everything in Typed >>>>>>>>> Racket, so I don't really understand what you're asking. Here are >>>>>>>>> examples of programs that will now type-error for each change. >>>>>>>>> >>>>>>>>> 1. (with-handlers ([void exn-message]) #f) >>>>>>>>> 2. (raise (lambda ([x : Integer]) x)) >>>>>>>>> >>>>>>>>> I think the second problem is more what you mean, in that the first >>>>>>>>> program is "wrong" in some sense, even though it doesn't go wrong, but >>>>>>>>> the second example is a perfectly fine Racket program (if perhaps poor >>>>>>>>> style), but not one that can be allowed in the presence of untyped >>>>>>>>> code. >>>>>>>>> >>>>>>>>> Does that help explain things? >>>>>>>>> Sam >>>>>>>>> >>>>>>>>> On Wed, Oct 29, 2014 at 5:17 PM, Robby Findler >>>>>>>>> <ro...@eecs.northwestern.edu> wrote: >>>>>>>>>> Sam: can you elaborate on precisely what the hole was? In particular, >>>>>>>>>> if there are any safe programs that the type system now rejects, I'd >>>>>>>>>> be in favor of a slightly different wording. >>>>>>>>>> >>>>>>>>>> Robby >>>>>>>>>> >>>>>>>>>> On Wed, Oct 29, 2014 at 2:35 PM, Sam Tobin-Hochstadt >>>>>>>>>> <sa...@cs.indiana.edu> wrote: >>>>>>>>>>> On Wed, Oct 29, 2014 at 3:30 PM, Ryan Culpepper <ry...@ccs.neu.edu> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> * Exception handling changed to be safe. This may break existing >>>>>>>>>>>> programs that rely on unsafe behavior. >>>>>>>>>>>> >>>>>>>>>>>> * Casts and predicates are supported in typed regions. >>>>>>>>>>> >>>>>>>>>>> I think these two bullets (esp the first one) need to make clear >>>>>>>>>>> that >>>>>>>>>>> they're about Typed Racket. >>>>>>>>>>> >>>>>>>>>>> How about: >>>>>>>>>>> >>>>>>>>>>> * Typed Racket's rules for exception handlers are now more >>>>>>>>>>> restrictive, as required for safety. This may cause type errors for >>>>>>>>>>> existing programs that rely on unsafe behavior. >>>>>>>>>>> * Typed Racket now supports casts and predicates in typed regions. >>>>>>>>>>> >>>>>>>>>>> Sam >>>>>>>>>>> _________________________ >>>>>>>>>>> Racket Developers list: >>>>>>>>>>> http://lists.racket-lang.org/dev >>>> _________________________ >>>> Racket Developers list: >>>> http://lists.racket-lang.org/dev >>> > _________________________ Racket Developers list: http://lists.racket-lang.org/dev
