emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]