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

On Wed, Oct 29, 2014 at 6:42 PM, Matthias Felleisen
<matthias at 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 <samth at 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
>> <samth at 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
>>> <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
>> _________________________
>>  Racket Developers list:
>>  http://lists.racket-lang.org/dev
>