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

properly -> corresponding fashion? 

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