Таким образом, пробелы, табуляторы и переводы строки (aka whitespace) вообще не имеют никакого значения? Весь файл можно записывать в одну строку? Тогда какие проблемы? Каждый байт может быть либо нужным, либо "ненужным". И это можно запросто проверить. Обычно, составить множество "нужных" байтов проще; например: буквы, цифры, подчёркивания, скобки... А всё остальное отбрасывать...

Или не так?

Весь файл действительно можно записать в одну строку. Но табы... Пробелы... Как мне отличать данные друг от друга? Но, в принципе, общая идея в чем-то правильная...

volodya
Отправил на mail.ru. Там 300к.

Все получил. Спасибо.

volodya> Пробелы... Как мне отличать данные друг от друга?

ОК. Тогда займёмся буквоедством. ;)

Задача лексического анализатора - собирать из букв слова (лексемы). Пробелы иногда необходимы, чтобы отделять друг от друга лексемы.

Например, в языке программрования Си, во фрагменте "void main" между словами "void" и "main" может быть любое количество пробелов, табуляторов и переводов строки. Но хотя бы что-нибудь одно из этого должно быть. Однако, на уровне синтаксиса это не имеет значения. Синтакисический анализатор получает от лексического два слова (на самом деле, некоторых условных кода aka токена): "void" (зарезервированное ключевое слово) и "main" (идентификатор). А то, что между ними есть пробел с точки зрения синтаксиса вообще "не видно". Пробел нужен только для того, чтобы лексический анализатор мог отделить их друг от друга.

Поэтому лексический анализатор обыкновенно работает так:
-- проскипать whitespace
-- начать собирать лексему
-- как только попадается байт, недопустимый для данной лексемы (например, скобка - это отдельная лексема), или попадается whitespace, то это означает, что лексема закончилась и её следует передать синтаксическому анализатору...

Вот. ;)

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

По-прежнему в голове слегка сумбурно... Значит так, лексический анализатор будет написан на основе JLex

взять тут:
http://www.cs.princeton.edu/~appel/modern/java/JLex/

Синтаксис у этой штуки примерно такой же как и у предлагаемых Sten'ом утилит.
Лексический анализатор используется только для парса хедера файла. Для парса собственно тела файла юзается стандартный

while ((line = rdr.readLine()) != null)

Теперь то, что до сих пор не совсем понятно мне. Т.к. captain cobalt буквоедством занялся непоследовательно и не до конца ;)

Вопрос:

Во входном файле есть три секции:

%objects
%common
%keywords

Хотелось бы, чтобы порядок следования мог быть любым. Каждая секция имеет открывающую и закрывающую фигурную скобки. Если какая-либо из них пропущена или поставлена лишняя и т.п. - то чья работа следить за порядком и за логикой расположения? Я правильно понимаю, что это работа драйвера лексического анализатора?

Пытаюсь налабать файл спецификации... Голова пухнет :)
Проблемка тут с возможными конфликтами... Что возникнет при таком конфликте я даже и не знаю пока...
Вот попытка что-то налабать... Правда, пока не очень рабочее.

/*** User code ***/


%%
/*** JLex directives ***/
DIGIT=			[0-9]
LETTER=			[a-zA-Z]
UNDERSCORE=		[_]
SPACE=			[\ \f\t\b\r\n]
OPEN_CURL_BRACKET=	[\{]
CLOSE_CURL_BRACKET=	[\}]
HANDLER_NAME=		({LETTER}|{UNDERSCORE})*
HANDLER_DATA=		\(({LETTER}|{DIGIT}|\||{UNDERSCORE})*\)
SECTION_HEADER=		%|({LETTER})*

%line

%%
/*** Regular expression rules ***/
{OPEN_CURL_BRACKETT}	{java.lang.System.out.println("Opening bracket: " + yytext()); }
{CLOSE_CURL_BRACKET}	{java.lang.System.out.println("Opening bracket: " + yytext()); }
{HANDLER_NAME}	{java.lang.System.out.println("Handler name: " + yytext()); }
{HANDLER_DATA}	{java.lang.System.out.println("Handler data: " + yytext()); }
{SECTION_HEADER}{java.lang.System.out.println("Section header: " + yytext()); }
{SPACE}*	{ }
. 		{ java.lang.System.out.println("Don't know what to do with: " + yytext()); }

Вопросы:
1)HANDLER_NAME должно матчить имена типа BIND_loc_site_source, Author и т.п. Я пока не уверен, что регулярка правильная.
2)С HANDLER_DATA вообще мрак. Все дело в том, что регулярка может элементарно содержать и пробелы, например:

Author (me, me again, aaa|bbb|12354|hehe@he.com)
Тут, случаем, нет конфликта со SPACE?

Кстати, в случае HANDLER_DATA лексический анализатор должен выдать только данные, без скобок, т.е. дано на вход (me, me again, aaa|bbb|12354|hehe@he.com), а выдается только me, me again, aaa|bbb|12354|hehe@he.com.

Переделал маленько...

/*** JLex directives ***/
DIGIT=			[0-9]
LETTER=			[a-zA-Z]
UNDERSCORE=		_
SPACE=			[\ \f\t\b\r\n]
OPEN_CURL_BRACKET=	\{
CLOSE_CURL_BRACKET=	\}
HANDLER_NAME=		[{UNDERSCORE}{LETTER}]*
HANDLER_DATA=		[\(({DIGIT}{LETTER}{UNDERSCORE}\ \\|,@})\)]*
SECTION_HEADER=		[%{LETTER}]*

volodya> Хотелось бы, чтобы порядок следования мог быть любым...
volodya> Я правильно понимаю, что это работа драйвера лексического анализатора?

Нет, неправильно. Это пойдёт в синтаксис.
Вот, например, в языках программирования есть операторы. Бывают операторы цикла, условия, присваивания, и т. п. Они тоже могут следовать в любом порядке. ;) Для каждого оператора есть синтаксическое правило. И каждое правило применяется для разбора соответствующего оператора.

Поэтому - для каждой секции написать синтаксическое правило.

volodya> С HANDLER_DATA вообще мрак... может ... содержать и пробелы
volodya> лексический анализатор должен выдать только данные, без скобок...

Это более серьёзно.
В "обычных" языках программирования для ограничения строковых констант используются кавычки. При этом используются они таким образом, чтобы у лексического анализатора хватило ума опознать и отпарсить строку.

Однако, в данном случае, как я догадываюсь, данные в скобках не являются единым целым. Скорее всего, данные, разделённые запятыми будут обрабатываться отдельно (например, вставляться каждый в отдельный элемент результирующего xml), не так ли? ;)

Если так, то скобки, несомненно, пойдут на уровень синтаксиса.

Всё остальное можно реализовать разными способами.

Лексический анализатор, действительно, можно "научить" отличать "значащие" пробелы от "незначащих". Однако для этого ему необходима некоторая "зацепка". В качестве такой зацепки могут выступать запятые\скобки, ограничивающие каждый элемент данных. То есть, будет лексическое правило: нечто, ограниченное скобками\запятыми - это элемент данных, который необходимо обрабатывать как единое целое вместе со внутренними пробелами...

Для повышения эффективности обнаружения ошибок можно было бы добавить к числу ограничителей, например, фигурные скобки и\или символ %. Тогда при "случайном" пропуске закрывающей круглой скобки это довольно быстро остановило бы рассматривание оставшейся части файла как "одного большого элемента данных". ;) Но тогда эти символы нельзя будет использовать в данных... В общем, вариантов много...

Мне кажется это довольнатаки интерестный вопрос ... может быть создать отдельную тему мол "Создания компилятора с 0" и объяснить и теорию и практику... как что куда и зачем... (в сети есть подобные темы но всё таки можно сделать всё очень конкретно и понятно) необязательно создовать компилятор и тди тп.. а просто научится парсить файл .. и тому подобное....

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

Нет, неправильно. Это пойдёт в синтаксис.

По-моему, мы говорим об одинаковых вещах, но на разных языках...
Еще раз.
От лексического анализатора я ожидаю одно - набор токенов. Не более, не менее. Как поступать с этими токенами - лексический анализатор не знает. Для этого нужна логика более высокого уровня. Например, пусть псевдокод выглядит так:

String token lexan(void); - типа метод класса, который возвращает токен.

Вот я в цикле опрашиваю lexan(). Где-то так:

if (lexan() == "SECTION_HEADER")

- мы встретили хедер секции, теперь ждем скобку (фигурная открывающая)

do
{
;
}while(lexan() != '{');

теперь ждем имена хендлеров + данные - опять lexan. И так до закрывающей фигурной скобки.

То, что ты понимаешь под синтаксисом... Для меня это звучит как синтаксический анализатор с его описанием грамматик. Если я правильно понимаю...

На уровне лексического анализатора, еще раз, я ожидаю только корректного возвращения токенов. А логику, которая знает, ЧТО делать с этими токенами я планирую реализовать как описано выше.

Однако, в данном случае, как я догадываюсь, данные в скобках не являются единым целым. Скорее всего, данные, разделённые запятыми будут обрабатываться отдельно (например, вставляться каждый в отдельный элемент результирующего xml), не так ли? ;)


Так, о великий! Ты прав :)

Если так, то скобки, несомненно, пойдут на уровень синтаксиса.

А поподробнее? Как выглядит процесс?

> От лексического анализатора я ожидаю одно - набор токенов. Не более, не менее.

Абсолютно правильно. ;)

> Вот я в цикле опрашиваю lexan(). Где-то так:
> if (lexan() == "SECTION_HEADER")

Тот, кто получает от lexan набор токенов, называется синтаксический анализатор. ;)

Проверки в цикле - это правильно (очевидно, там должна быть не одна проверка). Каждую такую проверку можно считать "распознавателем" синтаксической конструкции, чтобы потом осуществить собственно синтаксический разбор этой конструкции. Весь этот код в целом вполне является синтаксическим анализатором...

> А поподробнее? Как выглядит процесс?

В языках программирования бывают строковые константы. Они ограничиваются кавычками. Эти константы опознаёт по кавычкам лексический анализатор. При этом кавычки он "съедает" и собственно константу отдаёт без них. Кроме лексического анализатора в таком компиляторе вообще "никто" "не знает", что строки ограничены кавычками. Синтаксический анализатор и вовсе получает только код "строковая константа".

В рассматриваемой же ситуации со скобками всё наоборот. Как мы выяснили, каждый элемент данных будет обрабатываться отдельно. То есть, они будут раздельными на уровне синтаксиса. Поэтому и ограничивающие скобки также должны быть видимы, чтобы синтаксический анализатор мог определить, где параметры начинаются и где заканчиваются. Именно это и имелось под "скобки пойдут на уровень синтаксиса"...