This page is part of the web mail archives of SRFI 121 from before July 7th, 2015. The new archives for SRFI 121 contain all messages, not just those from before July 7th, 2015.
The rationale of Generators: It is basically a for the performance. Yes, lazy streams can do everything generator can do and more, so we won't need generators if the language has efficient integrated lazy streams. Unfortunately, lazy streams is not an integrated part of Scheme. On the other hand, Scheme already has some generator-like constructs: - Process input for each unit element (e.g. char/byte/sexpr) - Using random numbers - Retrieve rows of the result of DB query one at a time If the language had lazy-streams as one of built-in abstractions, these would've been natrually represented by lazy streams. But Scheme usually does not expose these kind of APIs using lazy streams. Generator-like interfaces are common, so it may be worth to have some common idioms extracted into a library. That's the motivation. Regarding performance, I found---at least in my implementation--- it is more efficient to create lazy streams on top of generators, than using the typical lazy-cons idiom. One example is shown here (scroll to "Examples" subsection): http://practical-scheme.net/gauche/man/?p=Lazy+sequences It's because lazy-cons requires to make a thunk for every item, while generators can generate items without consing (you still need one cell per item to make lazy list, but that is a normal cons and can be much ligher). Of course it depends on implementations. One can have super-light thunk creation. But I suspect in most implementations, thunk creation is slower than simple consing. John, I can rephrase this for the srfi's rational section, if you think this suits it. --shiro