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 <matth...@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
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
