properly -> corresponding fashion? 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