[racket-dev] Contract barrier inefficiencies

On Dec 29, 2012, at 10:09 PM, Neil Toronto wrote:

>>    TR proved that it is applied to Foo if anything. Is TR too
>>    aggressive in negative positions?
> 
> I'm almost certain it is. Sam? (Wherefore art thou, Sam?)
> 
> I can see an argument for having overly aggressive contracts at first, before having large test cases that demonstrate TR's implementation is almost always sound. If these are training wheels, though, we should consider removing them. The math library alone has at least 18k lines of TR code, it and exercises the type system pretty thoroughly.
> 
>> In this case, the chaperone is necessary, since the "a" means one value
>> (not multiple), so you cannot eliminate the contract. Sadly.
> 
> One asymmetry between multiple arguments and multiple return values is that the number of arguments a procedure accepts is observable, but the number of return values isn't. If it were observable, and TR were less aggressive with the first `Foo', a chaperone would be unnecessary.
> 
> There have got to be other uses for that, but I can't think of any offhand. Something to do with continuations, maybe? But TR could easily annotate lambdas with the number of values they return.


I have no doubt that right now we need a chaperone. I am arguing that we don't need a foo? check for the argument.