[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: Generators v2
From: |
Stefan Monnier |
Subject: |
Re: RFC: Generators v2 |
Date: |
Mon, 26 Aug 2013 12:05:52 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
> At https://github.com/dcolascione/elisp-generators, I've updated my
> elisp generator support. Please take a look.
I like generators, and your package looks interesting. I'd be very
happy to put it in GNU ELPA at least.
> integration, a few more testcases, and a lexical-binding assertion.
The top-level (assert lexical-binding) checks that lexical-binding is
true at run-time, whereas you only care about its value at
macro-expansion time.
> I'd eventually like to integrate this package into the Emacs core,
As I said, I like the idea. But I'm wondering how well it works
in practice. The code it generates seems to be extremely inefficient
(not that I know an easy way to make it more efficient, mind you).
> so I've laid claim to a few symbols in the global namespace, like
> next.
IIUC `yield' can only appear lexically within `defgenerator', so whether
its namespace-cleanliness is not much of a problem.
I see we already have `next' in Emacs's core, which we call `funcall'.
I agree that `funcall' is not an intuitive name, but I'm not sure I like
the idea of claiming `next' for it, right now. If/when generators move
to the core, I might change my mind, of course.
We could do away with the funcall altogether using an flet-like macro:
(flet-like ((g (y 10)))
(g)
(g)
(g)) => 7
> This package actually defines a generic iterator protocol, and
> it'd be useful eventually to define iterator objects for things like
> buffers and windows instead of relying on enumeration callbacks.
Agreed,
Stefan
- RFC: Generators v2, Daniel Colascione, 2013/08/25
- Re: RFC: Generators v2,
Stefan Monnier <=