5 ms·

Generators don't have either memory locality or fast indexing, which are basically the two defining features of an array in virtually every programming language

Generators don't have either memory locality or fast indexing, which are basically the two defining features of an array in virtually every programming language. They're nothing like arrays, except that you can iterate over them. That is, they're no more like arrays than trees, lists, and other iterable data structures are like arrays, which is to say, not particularly.

jkrems 12y ago
I'm not claiming they are like arrays as in "they have the same properties as arrays". I'm not talking about complexity of operations or even availability of operations. In the very beginning I name 3 categories. One of which is "data structures". And sets, lists, arrays, maps, etc. all are classical data structures. You can even - to some degree - interchange one for the other. It might not be efficient but they can simulate each other. E.g. you can implement a map in terms of a list, you can implement an "array-like" in terms of a list, etc.. I'm talking interface here, not complexity. But you can't implement a promise using an array. The array will never "magically" come to life a couple of seconds after you last touched it and do something. And that's the whole point of the gist.
- pdubroy 12y ago
  You also can't implement generators using an array. There's a reason why generators were added to ES6 -- they aren't just syntactic sugar.
  - jkrems 12y ago
    If they aren't just syntactic sugar - how to you think regenerator works? Show me a generator and I show you perfectly fine, synchronous (though verbose) ES5 code doing the exact same thing.
    - pdubroy 12y ago
      Well, "syntactic sugar" usually refers to things that can be translated in a syntactically local, structure-preserving way. I'm aware that generators can be compiled down to an ES5 representation, but it requires non-trivial analysis. Take a look at the example on their home page: https://facebook.github.io/regenerator/ https://facebook.github.io/regenerator/. Do you also consider functions to be syntactic sugar? Because you can also implement them in terms of a switch statement.

jkrems 12y ago

I'm not claiming they are like arrays as in "they have the same properties as arrays". I'm not talking about complexity of operations or even availability of operations. In the very beginning I name 3 categories. One of which is "data structures". And sets, lists, arrays, maps, etc. all are classical data structures. You can even - to some degree - interchange one for the other. It might not be efficient but they can simulate each other. E.g. you can implement a map in terms of a list, you can implement an "array-like" in terms of a list, etc.. I'm talking interface here, not complexity. But you can't implement a promise using an array. The array will never "magically" come to life a couple of seconds after you last touched it and do something. And that's the whole point of the gist.

pdubroy 12y ago
You also can't implement generators using an array. There's a reason why generators were added to ES6 -- they aren't just syntactic sugar.
- jkrems 12y ago
  If they aren't just syntactic sugar - how to you think regenerator works? Show me a generator and I show you perfectly fine, synchronous (though verbose) ES5 code doing the exact same thing.
  - pdubroy 12y ago
    Well, "syntactic sugar" usually refers to things that can be translated in a syntactically local, structure-preserving way. I'm aware that generators can be compiled down to an ES5 representation, but it requires non-trivial analysis. Take a look at the example on their home page: https://facebook.github.io/regenerator/ https://facebook.github.io/regenerator/. Do you also consider functions to be syntactic sugar? Because you can also implement them in terms of a switch statement.