[racket-dev] Release Announcement for v6.1.1, Second Draft

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
<samth at cs.indiana.edu> wrote:
> On Wed, Oct 29, 2014 at 5:47 PM, Robby Findler
> <robby at 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
>> <samth at 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
>>> <robby at 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
>>>> <samth at cs.indiana.edu> wrote:
>>>>> On Wed, Oct 29, 2014 at 3:30 PM, Ryan Culpepper <ryanc at 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