[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI 121: Generators

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

- 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):


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.