Hi Marc, and thanks for your responses. On 2022-09-03 20:18 +0200, Marc Nieper-Wißkirchen wrote: > > That's all right, as long as you test 'promise?' before 'procedure?', thus: > > > > (cond ((promise? thunk) > > (force thunk)) > > ((procedure? thunk) > > (thunk)) > > (t (error "not a thunk"))) > > > > or more simply: > > > > ((promise? thunk) (force thunk) (thunk)) > > That would work if all procedures returned by "lambda" and by all > other procedure constructors but "force" and "make-promise" and using > only the standard exports of R7RS to construct them are guaranteed to > be disjoint from possible values on which "promise?" returns true. I > may be wrong but I currently don't see where R7RS makes this > guarantee.
Is there any serious danger of unexpected behavior resulting from the above code, though? If an implementation’s ‘promise?’ is true of (some) thunks, then I’d expect (force thunk) to evaluate to (thunk). If it instead returned ‘thunk’, say, then it would be a problem for us, but it would also be a poor implementation. Thus I don’t see any practical objections to this kind of dispatch. You might argue that the promise version of ‘if-procedure’, etc. belong in a different library, perhaps a library of useful delayed-evaluation forms. Maybe so. To me, they seem similar enough to the thunk versions to warrant unifying them. -- Wolfgang Corcoran-Mathe <[email protected]>
