I am very surprised with the stuff shown in this talk. One would think that by using a more explicit syntax, the compiler/interpreter has more context to optim

I am very surprised with the stuff shown in this talk. One would think that by using a more explicit syntax, the compiler/interpreter has more context to optimize and do things faster. Looking at the destructuring example, it seems like part of the problem is that the new constructs are actually more general, since their semantics are defined in terms of iterators in order to support user defined types... I guess, on the other hand, this still allows for better overall system performance (e.g. one can now pass lazy-evaluated transformations instead of producting new arrays all the time when writing functional-style code.). An alternative would be to have sepparate syntax [a, b, c...] for arrays and (a, b, c...) for iterator based destructuring. There is the risk then that then everyone starts using the former syntax for the sake of premature optimization and we end up with over-restrictive API's that then disable the opportunities for lazy-evaluation and so on described before. Definitely and interesting case. It would be nice to be able to read some of the discussion of the standardization process and see how these performance trade-offs where considered. Anyone has some pointers?