[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: Generators v2
From: |
Stephen J. Turnbull |
Subject: |
Re: RFC: Generators v2 |
Date: |
Mon, 26 Aug 2013 12:53:22 +0900 |
Daniel Colascione writes:
> 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.
Well, yeah, true iterators would have to be implemented at the C level
to be efficient, or you'd need to use an iterator-only function to
iterate one. But almost 10 years of Python experience shows that
Python-style iterators and generators (especially genexps) beat pretty
much everything users actually write instead.
> 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. :-)
I have no idea what you're talking about. Meat isn't *sweet*,
generators are. :-)
> 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.
Only if you restrict yourself to implementing your iterators as
"dotted lists of vectors with the last cdr being
'supercalifragilisticexpialidocious".
> What's the alternative: a special kind of cons cell that lazily
> generates its car and cdr?
No. A new iterator type. A lazy cons is an interesting idea, but
it's different and not very Lisp-y IMO (since Lisp doesn't have
laziness built in elsewhere). (car iterator) doesn't really make
sense, to me, anyway. Merely accessing an iterator should mutate it,
that's what it's for.
> Providing ways to conveniently iterate over iterators (and making
> these constructs also handle today's sequences) would be
> sufficient. There are only a few.
I suppose that's true, since `while' doesn't provide enough syntax to
take advantage of iterators. But I worry more about uses which pass
an iterator accidentally to an unprepared iteration, or call it as a
function and corrupt the internal state, than about strange behavior
of a new type. New types are expected to behave strangely!
> I suppose it's possible to wrap the returned function in some
> easily-distinguishable wrapper, but why would you want to?
Well, for one thing, iterating an ordinary function is an infloop
waiting to happen.
Steve