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

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
<robby at 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
> <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