Как интерпретатор js отличает знак деления от слешей в /inlineRegExp/ ?
 

Как интерпретатор js отличает знак деления от слешей в /inlineRegExp/ ?

Мне нужно на js написать парсер находящий в коде все комментарии, строки и регулярки (inline).
Со строками я уже все придумал, можно считать, что в коде их уже нет. Комментарии регулярки и деление содержат слеш, нужно их разделить. С комментариями все просто: смотрим следующий после слеша символ, если это еще один "/" или "*", то комментарий.
С отделением деления от регулярки у меня выходит примерно такой план: смотрим теперь уже предыдущий перед слешем символ, игнорируя пробельные символы, если это "(", то либо регулярка стала первым аргументом при вызове функции, либо:
т. е. просто регулярка в скобках. Еще может быть "," , т. е. регулярка стала вторым аргументом при вызове (аргументом массива и т. п.), использование деления в этом случае не допускается. Еще символы "=" и ":", теперь регулярка присваивается переменной/свойству, опять же деление в такой конструкции недопустимо.

Пока, получается, нужно искать любой из символов "(,=:" , игнорируя пробельные символы. Если найден - регулярка, нет - деление.

Вопрос: что я забыл? Или может вообще неправильный план?

Т.е. ты просто вырезаешь кавычки? А если они внутри комментария? А если так?

/* " */ var str = "asdf";

alert(/^\//);

Я вижу только одно решение: полноценный парсинг.
http://github.com/ry/node/wiki/modul...ser-generators

Алгоритм задумывается не такой, как обычно делают (для клиентской подсветки синтаксиса, серверные варианты я не смотрел, но где-то читал, что они лучше). В обычных алгоритмах, например, сначала ищутся все строки, потом комментарии, в результате вот это:

/* " */ var str = "asdf";

действительно будет неверно распознано. Если изменить порядок поиска, т. е. теперь сначала комментарии, потом строки, все будет как надо, но лишь до тех пор, пока не попадется что-нибудь вроде:

var str = "as/*df";/* " */

Другими словами обычные алгоритмы сначала ищут какие-то конструкции одного типа, затем другого (там конечно похитрей все, но суть примерно такая). В своем варианте я хочу сделать, чтобы искалось как бы все сразу, последовательно. Будет что-то вроде анализа кода слева направо, подобно тому, как это делают интерпретаторы. В результате ошибки с распознаванием подобных конструкций:
уже исключаются.

Далее алгоритм, найдя конструкцию какого-то типа, например строку, переключается в другой режим, применительно к строке это будет режим поиска окончания строки. За счет переключения режимов, ошибки вроде этой:

alert(/^\//);

так же исчезнут: режим поиска окончания регулярки уже не будет реагировать на два слеша как на комментарий.

Тут конечно много всего придется предусмотреть, например, кавычка в строке может быть экранирована, т. е. это уже не конец строки. Причем мало просто смотреть есть перед кавычкой слеш или нет, нужно считать количество этих слешей т. к. если их четное количество, то экранируют они только сами себя. Могут быть многострочные строки:

var x = 'as\
df';

Многие ЯП поддерживают строки которые воспринимаются "как есть": C# :

string s = @"asdf\";

в примере вторая кавычка вовсе не экранирована.

В общем, как-то сложно все это выглядит.

Я и говорю, в результате придёшь к полноценному синтаксическому разбору по грамматике.

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

Чему там тормозить-то? Один проход по строке.

Только эта строка может быть большой. И еще ключевые слова заменяются не во всей строке сразу, а в кусочках, которые получились между строками, регулярками и комментариями, т. е. много-много срабатываний одной и той же регулярки (которая, кстати, довольно тяжелая: /(while|for|in|.....mnogoKeyworlds.....)/g).

Ну вот погоняй, чё рассуждать-то.