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
