В данном случае, для получение значений массива использовать нужно именно of, а не in.

ой ли?
вот две записи, дающие одинаковый результат

result_in = ( val for val in ['a', 'b', 'c'][0...2])
result_of = ( val for key, val of ['a', 'b', 'c'][0...2])

Но почему первая — корректна, а вторая — путь на темную сторону?
Потому что:

var key, result_in, result_of, val;

result_in = (function() {
  var _i, _len, _ref, _results;
  _ref = ['a', 'b', 'c'].slice(0, 2);
  _results = [];
  for (_i = 0, _len = _ref.length; _i < _len; _i++) {
    val = _ref[_i];
    _results.push(val);
  }
  return _results;
})();

result_of = (function() {
  var _ref, _results;
  _ref = ['a', 'b', 'c'].slice(0, 2);
  _results = [];
  for (key in _ref) {
    val = _ref[key];
    _results.push(val);
  }
  return _results;
})();

Мы же не будем спорить о том, насколько неэффективно обращаться с массивом как объектом?

Алсо —

expr = /foo*/g;
alert "#{array[0]} : #{expr.lastIndex}" until (array = expr.exec('foofoo')) is null

пример явно не удачный, потому как это же явно

expr = /foo/g
console.log "#{array[0]} : #{expr.lastIndex}" while array = expr.exec 'foofoo'

Алсо —

alert i for i in [1..10] when i % 2 is 0

ИМХО удачнее будет

for i in [1..10] when not( i % 2) then console.log i

Алсо — с места

[value for i, value of ['a', 'b', 'c'][0...2]] # a, b

и до конца раздела — это вы о чем?
Во-первых не нужно писать of [arr], нужно in [arr]
Во вторых — смысла конструкции вообще не понял — может проще сразу было

 ['a', 'b', 'c'][0...2]

не?

Эм, за напоминание о слайсах — спасибо, в отместку — там опечатка есть

[list1, list2 ...]  #[1,2,3,4,5,6] 

Не, чтобы получить плоский список надо сказать

[list1..., list2...]

лучше null

Бла-бла-бла — кидалтское нытье и занудство.

Автору стоит вернуться к взрослой реальности.
Не хотите наш CS — ну и xрен с вами! Не нравится ответ на SO на CS — ну и хрен с вами!
Это ваши проблемы и не вам мне указывать где что и на чем писать.
Я же не начинаю ныть, что вот тут книжка по алгоритмам на сях, тут — на лиспе, а тут вообще не пойми чего? Раз оно надо мне, значит и с этим я разберусь.

Ну, многослойные абстракции нам дает DI, за связанностью следит ООП, а сокращать код помогают mixin-ы.

Я как бы не настаиваю, но есть некие best practice, игнорировать которые черевато боком, мне ли не знать.

Но в любом случае — успехов, хоть я лично за unix-way и держусь подальше от комбайнов.

Есть такой вопрос провокационный — а почему Вы не пишите на node.js?

Зачем Вы изобрели собственный механизм импорта\экспорта?
Почему не используете сторонние клиентские библиотеки — для работы с датой, строками и т.д? Всякие lodash-underscore уже стандарт де-факто.

Я уж молчу про то, что использование global — жуткий моветон, который еще как-то можно простить в тестах, но в продакшен-коде — ни-ни.

Что-то мне подсказывает, что криворукие люди не напишут в продакшен машину регулярных выражений.

А что быстрее будет работать — честно говоря пофик, микрооптимизации меня никогда не интересовали.

Только ComonJS, только хардкор :)

Пишем на coffee, жмем clinch-ем и вуаля!
Получается что-то типа такого — демо и исходники.

Ниже куча ссылок на подобные проекты.
Плюс еще есть TinyData, которая полноценный запросник по слабоструктурированным данным :)

Ну, этой книги у меня нет, однако если мы о тупом баге в стеках — то он довольно давно поправлен почти во всех браузерах.

Изменения в спеках и объяснялка на SO.

Я вот знаю про скрытые классы при создании объекта, про преобразования массива если он содержит разные типы данных, про преобразование полиморфных функций, а вот по поводу «скомпилированной сущности» в отношении регулярок — не, не видел. Может лишнего удумали?

О как.
Могу я попросить ссылку на документацию (вероятно в реализациях браузеров?) об этом факте?

ХМ… пруф?

У меня вот как-то другие получаются результаты:

  var n, re1, re2, res;

  re1 = /test/;

  re2 = /test/;

  res = (function() {
    var _i, _results;

    _results = [];
    for (n = _i = 0; _i <= 1; n = ++_i) {
      _results.push(/test/);
    }
    return _results;
  })();

  console.log('re1 === re1 ->', re1 === re1); // re1 === re1 -> true

  console.log('re1 === re2 ->', re1 === re2); // re1 === re2 -> false

  console.log('res[0] === res[1] ->', res[0] === res[1]); // res[0] === res[1] -> false

Или я не верно понял идею?

поиск продолжается с места предыдущего найденного результата

Это о чем? я знаю только о поведении реплейса с флагом 'g' и экспериментальном флаге 'y', но у нас тут другая ситуация вроде.

PS. А за что человека-то заминусовали — все верно заметил.

Кто знает :) Строим на века, вдруг в этом месте будет лаг и интерфейс пользователя фризоваться начнет? :)

На мой вкус ничего там делать было не надо, данных проФайЛера (я правильно понял?) не было конечно — virgin premature.

Ох.
Уж положа руку на сердце по-моему там вообще ничего оптимизировать не надо.
Тем более изобретать велосипедов и «обходится без регулярки».
Регулярные выражения — простой и выразительный способ описания алгоритма обработки грамматики, с первого взгляда объясняющий что, зачем и почему тут происходит.
Более того — я твердо верю что это лучший и безальтернативный способ работы с грамматиками — так что их надо тупо выучить и применять.

Ну и основная идея поста была не в том, что что-то можно оптимизировать, а в том, что это накладно. Я не оперирую терминами «читабельность» и т.д. Тупо цифры: сложность — +столько-то, размер — +столько-то, effort — +столько-то. И в итоге поддержка кода превращается в ад. Как бы так вот.

PS. хм, ну и на что тут будет похож вариант «без регулярок»?

Погуглил про interning, выяснил что JS сам интернит строки-как-литерал, а динамически создаваемые — нет.
Однако идеи приведенного примера так и не понял — есть переменная, которая не используется, замыкание по идее возвращающее то же самое — профит-то в чем?