Lets say I have a function that gets a list of promises or lists. It
is going to print out the state of some ongoing computation (that is
producing these lists). It will print the list, if there's a list, and
it will print "pending" if it is a promise; it doesn't want to force
it, since it is just a view.
Somewhere else, something is building new lists-- when it decides to
force something, it replaces the promise in the list with the forced
value and then hands a new list off to the view.
(But in general, it just seems useful to be able to ask if something
is a promise without forcing it.)
Robby
On Fri, Jul 6, 2012 at 4:53 PM, Matthias Felleisen <matth...@ccs.neu.edu> wrote:
>
> 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 <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
