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

On Wed, Oct 29, 2014 at 6:57 PM, Matthias Felleisen
<matthias at ccs.neu.edu> wrote:
>
> properly -> corresponding fashion?

No, it's a different change (the one I numbered 1. in my first message).

Sam

>
> Otherwise fine
>
>
> On Oct 29, 2014, at 6:54 PM, Sam Tobin-Hochstadt <samth at cs.indiana.edu> wrote:
>
>> 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
>>>
>