[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: Generators v2
From: |
Daniel Colascione |
Subject: |
Re: RFC: Generators v2 |
Date: |
Sun, 25 Aug 2013 13:00:11 -0700 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 |
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