[racket-dev] promise vs polym contracts

I can't think of such a primitive other than force, for which it is okay. Can you be concrete? 



On Jul 6, 2012, at 5:16 PM, Robby Findler wrote:

> What do you do if you have a function that accepts either promises or
> lists? Then, you might want total predicates.
> 
> Robby
> 
> On Fri, Jul 6, 2012 at 2:22 PM, Matthias Felleisen <matthias at ccs.neu.edu> wrote:
>> 
>> I just realized that Racket already suffers from the problem that polymorphic contracts introduce.
>> 
>> As Stephen is working out right now, Racketeers want to introduce laziness to speed up programs on occasion. We have been told for decades that delay and force are our friends. In a sense, this performance-refactoring problem is exactly the same problem as incremental type refactoring aka gradual typing. You want to add laziness in a transparent manner -- or if you make a mistake, it should blow up on you.
>> 
>> But it doesn't:
>> 
>>> Welcome to DrRacket, version 5.3.0.13--2012-07-05(467bde3a/d) [3m].
>>> Language: racket.
>>>> (null? (delay (/ 1 0)))
>>> #f
>>>> (zero? (delay (/ 1 0)))
>>> . . zero?: contract violation
>>>  expected: number?
>>>  given: #<promise:unsaved-editor12957:6:9>
>> 
>> For some reasons I don't understand, our ancestors (let's not use their name anymore) decided to make some primitives resistant to promises and some aren't. Now imagine you accidentally package a null in a delay, which may happen when you use lazy combinators:
>> 
>>>> (null? (delay null))
>>> #f
>> 
>> Your program changes meaning and off it goes and signals an error. You don't get a faster program, you get a program that raises the wrong kind of error.
>> 
>> What they should have done is signal an exception when strict primitives receive a promise.
>> 
>> I take it is too late to correct such a {\HUGE HUGE} historical blunder. -- Matthias
>> 
>> 
>> _________________________
>>  Racket Developers list:
>>  http://lists.racket-lang.org/dev