[racket-dev] Contract barrier inefficiencies

On Dec 28, 2012, at 8:04 PM, Robby Findler wrote:

> Overall, I feel like some of what you're asking has to do with what TR is doing and some with what's going on inside the procedure chaperones and so I'm not sure the contract library itself is a place where fixes can happen.


I think the questions really concern the interaction between TR's generation of contracts and contracts themselves:  

 1. TR does not seem to exploit as much knowledge as possible when it generates contracts. 
	Example: (All (a) ((Foo -> a) Foo -> a) seems to be such an example (perhaps extreme)
	Where can Foo come from? Why does TR wrap a contract around the domain of Foo -> a -- 
	TR proved that it is applied to Foo if anything. Is TR too aggressive in negative positions? 
 
 2. Multiple crossings impose the same contracts over and over. BUT 'same' is not necessarily 
	expressed as eq?. Can the contract library do better here? Is the 'inner loop' assumption 
	wrong? 

 3. And then there seems to be a chaperone question, though I don't understand that one. 


	
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20121229/409e149c/attachment.html>