4 ms·
First of all this is very nice. (I'm going to get a little negative shortly; I want to be clear that I'm not putting down the writer's efforts at all.) Several
by ggchappell 15y ago
First of all this is very nice. (I'm going to get a little negative shortly; I want to be clear that I'm not putting down the writer's efforts at all.)
Several commenters have compared these streams to Python generators. Yes, the two are similar. But there are are a couple of important things Python generators have, that these don't.
(1) Python generators, along with lists, tuples, files, net connections, etc., all support the standard iterator protocol. This means that, for many purposes, you don't need to know or care which kind of data source you are reading from. The itertools functions can be applied to all of them, etc. In contrast, these JS streams are dealt with via specialized member functions. You can't just take array-based code, pop in a stream, and expect it to work.
(2) The iterator returned by a Python generator is a wrapper around a single running computation, which can spit out multiple values. Retrieving a new value is not, at heart, a function call, but rather the continued execution of a coroutine that has already started. This has many advantages; for example, we can write a Python generator that produces an infinite dataset, using a simple loop. I don't think that works here.
Now, as for (1) above, I think this is something we could do in JS. It would just be a matter of everyone agreeing to support a particular interface.
OTOH, it seems to me that JS does not have the functionality to support (2). Python does. So do Ruby, Haskell, and Go -- each in its own way. But JS does not, AFAIK. Am I wrong? And should we be building support for (2) into JS and other languages?
-----
BTW, I find these streams to be pedagogically interesting. Unlike, say, Haskell lists, the thunks in the data structure can be stored explicitly. It's a nice exercise in the actual implementation of a lazy sequence.
- dionyziz 15y agoHi ggchappell. First of all, thanks for your feedback. You're quite right about (2); but there's a new Javascript version coming out soon that proposes generators and 'yield' similar to how Python uses them. When it comes out and is supported by most browsers, we can probably implement that (or just use native syntax and get rid of stream.js altogether). As for (1), I'd be happy to hear a proposal. If you'd like to work on this, feel free to submit an issue or even a pull request on github — suggestions like this are very welcome. Thanks! :)
- buddydvd 15y agoHere's a project that simulates the "yield" keyword with current version of JavaScript: https://bitbucket.org/balpha/lyfe/wiki/Home https://bitbucket.org/balpha/lyfe/wiki/Home
- ajuc 15y agoThanks for this link, I've been looking for something like that. Generators like in Python allow for nice AI scripting with explicite time-sharing - each AI actor is generator function, that in main loop has yield statement. That way it all works in one thread, and ai code can be written straightforward, like each actor had it's own thread.
- ggchappell 15y agoWell, I'm certainly no JS expert. I doubt I'm the guy to figure out what to do here, at this point. In any case, are you sure that JS generators should be considered a "future" thing? I just did a bit of research, and it sounds like you are talking about this proposal: http://wiki.ecmascript.org/doku.php?id=proposals:iterators_and_generators http://wiki.ecmascript.org/doku.php?id=proposals:iterators_a... According to the following page, much/all of that proposal was included in JS 1.7, which was implemented in Firefox 2.0. https://developer.mozilla.org/en/New_in_javascript_1.7 https://developer.mozilla.org/en/New_in_javascript_1.7 And FF 2.0 was released in October 2006. A quick check shows that my FF installation (3.6.22) supports generator functions, and the "yield" keyword, just fine, as long as I say <script type="text/javascript;version=1.7"> Regardless, I'm a little out of my depth here.