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

On Wed, Oct 29, 2014 at 9:46 PM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> I don't think that "it's true of every type system everywhere" is a
> good rationale for not owning backwards-incompatible changes (even
> when they are "good" backwards incompatible changes, as this one
> certainly is). I do agree with you, however, that what is especially
> bad is requiring changes to "working" code bases (for whatever
> definition of that word you wish to take (that is most friendly to
> people that use Racket)).

I don't think I was not owning the existence of a
backwards-incompatible change. I just don't think that the distinction
about whether it rejects programs that run correctly is meaningful --
the other change to exception handling only affects programs that were
wrong, but has been a bigger issue in practice.

> How about this one? (Starting from Matthias's offering and editing the
> apology from Sam's a bit.)
>
> Typed Racket closes a safety hole in the typing 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. As a side-effect, previously
>   well-typed programs may fail to typecheck.

How about:

 Typed Racket now checks uses of the exception system more strictly,
eliminating safety bugs. The revised type system restricts raise so
  that only instances of the exn structure type and flat data
  are communicated to handlers, and enforces that exception handlers
deal with all possible arguments. As a side-effect, previously
  well-typed programs may fail to typecheck.

Sam

>
> Robby
>
> On Wed, Oct 29, 2014 at 5: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.