[racket-dev] TR: Five feature/limitation interactions conspire to drive mad

From: Sam Tobin-Hochstadt (samth at ccs.neu.edu)
Date: Mon Dec 31 18:32:22 EST 2012

On Mon, Dec 31, 2012 at 4:56 PM, Vincent St-Amour <stamourv at ccs.neu.edu> wrote:
> In general, we need a better story for scaling up programming with
> intersection types.

I agree with this.

>> There are two more general solutions to the first problem, that
>> single-arity `case->' types sometimes make annotating impossible:
>>
>>   5. Find some way to name the polymorphic arguments in `case->' types.
>>
>> Yes. This. At least 25% of my time refactoring `math/matrix' has gone to
>> writing twisty, annotation-free function bodies.
>
> I agree that this would be useful. Sam, do you think this is doable?

I'm not sure that an ad-hoc naming solution is the right thing.  I
really want to avoid adding more ad-hoc complexity to the Typed Racket
type checker, and instead work on simplifying it into something that
can be more precisely characterized, and thus be more sure that it's
implemented correctly.

Is there a generalization of this solution that we can give a clean story for?

Sam

Posted on the dev mailing list.