Re: RFC: Generators v2

[Daniel Colascione]

On 8/25/13 6:56 AM, Stephen J. Turnbull wrote:
> Nic Ferrier writes:
> 
>  > I'm personally uncomfortable about claiming `next'. At least use a
>  > better name, like `gen-next'?
> 
> Another possible name is `pop', I think.  `pop' being a macro anyway
> it should be able to handle Yet Another Type of argument.  `pop',
> because when applied to arguments, a generator returns an iterator
> whose API is like a list restricted to being consumed by iteration.  I
> like `next', though.  `next' is used in Python, at least, and it seems
> like the natural name to use.  `gen-next'?  No, thank you.


I also like the idea of using pop, but you'd have to determine at
runtime whether you were popping from an iterator or a list, and I'm not
really comfortable adding that overhead. I'd prefer 'next' over
'gen-next' or other alternatives: we're talking about a generic
iteration protocol. The chief problem with using generic names is that
they're often tied to concepts that are too specific. In this case,
though, we're giving a generic concept a generic name, and I think
that's fine.

> 
>  > Perhaps it would be possible to avoid grabbing next by making it an
>  > argument to the object returned by yield:
>  > 
>  > (defgenerator y (x) [...])
>  >
>  > (let ((g (y 10)))
>  >   (funcall g :next)
>  >   (funcall g :next)
>  >   (funcall g :next)) => 7
> 
> I think the package is misusing the name "generator".  If `g' is a
> function (which it seems it indeed is in this package), it's already
> possible to create closures in various ways, so that a function
> carries its state with it.  So this is just syntactic sugar for
> closures.

The package uses a tree walker to rewrite swaths of code into
continuation passing style. If you think that's sugar, I'd love to see
what you consider meat. :-)

> Indeed this syntactic sugar is *very* useful for coroutines and the
> like, but it's not really useful for generators.  The point of a
> generator is that it returns an iterable, ie, an object which looks
> like a sequence in an iteration context.  In particular, code that can
> iterator over the value of a generator should be able to use an
> ordinary list in the same place, *without* knowing which it's going to
> get in advance.  

Ideally, yes, and in something like Clojure, we'd be able to do that
with existing languages primitives --- but here, our options for runtime
polymorphism are limited. Providing ways to conveniently iterate over
iterators (and making these constructs also handle today's sequences)
would be sufficient.

I don't see how you make that work generically if
> generators return functions.  You have to alter *every* iteration
> construct to recognize generators.

There are only a few. What's the alternative: a special kind of cons
cell that lazily generates its car and cdr? I suppose that could work,
but I'd be worry about unintended side effects.

> And then what happens if you hand
> it an ordinary function?  Is it possible to distinguish between a
> function created with defun, and the value of a generator created with
> defgenerator?  I don't see how (without introspecting the code for
> yields).
> 

I suppose it's possible to wrap the returned function in some
easily-distinguishable wrapper, but why would you want to?

signature.asc
Description: OpenPGP digital signature