> Well, think about `delay' as it's used in most Scheme implementations: > you use it in specific contexts where usually you know in advance that > you're not worried about exceptions -- if an exception always > indicates a bug, then it doesn't matter that forcing some promise > throws an exception, and a later force doesn't -- either way it's a > bug that you need to resolve, and when the bug is gone you're back > into "don't care about exceptions" mode. > > But if you want to implement a lazy language, then the perspective > changes, and you certainly want that consistent behavior. Same as > racket itself -- if exceptions *always* indicate a bug in your code > then there's no real need for making up the machinery to capture them > etc, you can get away with reporting the problem and then segfault > your way out of the process.
I am interested in lazy evaluation in the context of effectful call-by-value languages and I do care consistent behavior. Also, I am not convinced if I'll be willing to crash the system when initialization fails or throw uncaught exceptions... This said, if I commit to that initialization is performed only once, raising exceptions for black holes and memorizing exceptions seem only natural. Well, I could instead silently diverge! > But a bit more than that, I made `lazy' promises usable as the end > points also, which means that you can use them too -- provided that > you don't need multiple values. In fact, I think that in general > using `lazy' is better since it composes -- it's in perfect analogy to > tail calls: it's true that you don't always need them, but by getting > them wherever possible "good things happen", including situations > where you didn't realize that you need it. So if you're using `delay' > you're making sure that promises don't compose, whereas a consistent > use of `lazy' will give you that when needed. But 'lazy' could incur tag-check twice when 'delay' does just once? Also 'lazy' may involve two indirections when 'delay' does one? I.e., I thought there is trade-off. Keiko _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
