> So you shouldn't use it at all. I wouldn't if I saw any hints :) > The way the lazy language works, any function that is defined outside > of the lazy world (and is not a struct constructor) is considered > eager, so arguments that are sent to it are forced Yes, that's pretty clear.
> (That's something to know to do the code splitting that Matthias is talking > about.) Going back to this, I often find that I want to use laziness as an interface. That is, I build a system as a collection of components, written in a strict language because of familiarity/performance/ease of reasoning (especially in non-pure language)/etc, which are glued with lazy streams to make calculations demand-driven. This is known as generators and I think is a popular simple model. In this case I don't want any module to live completely in the lazy world, I only want a lazy interface. > Right -- on the strict side you'd want to use forces when needed. As an aside, why strict take has arguments in reversed order compared to lazy take? > The internal representation of sequences should change[...] Sequence protocol as exposed by make-do-sequence is probably the most complicated sequence protocol I've seen. Is it documented somewhere why standard sequence/iterator divide is not used? In that case sequence is stateless (or memoized) and iterator is statefull, but usually short-lived. Also, each sequence can provide multiple iterators, such as reverse or memoizing. The latter allows programmer to decide what he wants in a particular case. > I thought that there was some warning there... I'll add one. Thanks. Eugene _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
