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
