Ага. Моя вина. Не совсем точно сформулировал условие. Нет, я хочу чтобы данные для хендлера были одной строкой с точки зрения синтаксиса. Т.е. если я имею нечто в скобках, лексический анализатор должен убрать скобки и выдать на выход собственно это самое нечто.

Так что нет нужды выносить эти операции на уровень синтаксиса. Уровня лексики вполне должно хватить.

Да?
А кто будет отделять друг от друга параметры?
Синтаксический анализатор?
А как он это будет делать?
Анализировать по одной букве?
Не кажется ли, что дважды анализировать один и тот же фрагмент по одной букве "неэкономично"? ;)

А кто будет отделять друг от друга параметры?

Хендлер. Он знает, что куда пихать. Более того, для каждого хендлера могут быть свои правила. Так что, от лексера надо лишь подать то, что в скобках, без изменений. Вот и все.

Не кажется ли, что дважды анализировать один и тот же фрагмент по одной букве "неэкономично"? ;)

Думаю, вопрос снят.

Токен - это синтаксически неделимая единица.

Если токен после того, как он собран, начать обратно разделять на части, это, мягко выражаясь "неклассический подход". ;)

Хм... Ну тогда все значительно усложняется. Опять таки, строка для хендлера вполне может содержать пробелы. Как поступать в таком случае? И плевать мне, что подход будет неклассическим... Зачем самому себе устраивать головомороку?

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

А правила хендлера == синтаксические правила.

Пардон, не пойду по твоей дороге. Все, что в скобках - подается на вход хендлеру. Точка.

За дискуссию и прояснение некоторых моментов для меня - большое тебе спасибо.

В качестве генератора лексического анализатора буду юзать Jlex. Он похож на lex/flex. Роль синтаксического анализатора будет играть моя собственная логика + хендлеры. Такая архитектура вполне для меня удобна и логична. Хендлер "сам" решает в каком формате данные должны поступать на вход. Дело лексера - их ему предоставить.

> Опять таки, строка для хендлера вполне может содержать пробелы. Как поступать в таком случае?

Если запятые используются только для разделения параметров хендлера, то лексер может "цепляться" за эти запятые и за окружающие круглые скобки.

Аналогично тому, как лексер языков программирования "цепляется" за окружающие стринг кавычки, и "понимает", что пробелы между ними "имеют значение"

> Пардон, не пойду по твоей дороге. Все, что в скобках - подается на вход хендлеру. Точка.

имхо, было бы проще ;)

Может быть, я уже просто не могу понять, что ты хочешь до меня донести.

Если запятые используются только для разделения параметров хендлера, то лексер может "цепляться" за эти запятые и за окружающие круглые скобки.


Да, это правда. Запятые используются для разделения параметров.
Как это дело происходит сейчас.

Вот, что я получаю из движка:

	public static final int initCommonHandlers(String h_name, String h_data)
	{
		if(h_name.indexOf("Author") != -1)
		    return processAuthor(h_data);

		if(h_name.indexOf("BIND_pub_object") != -1)
		    return processPubObject(h_data);

		if(h_name.indexOf("BIND_Interaction_division") != -1)
		    return processDivision(h_data);

	    return -1;
	}

String h_name - название хендлера
String h_data - данные, передаваемые хендлеру.

Например, хендлер Author.

	private static int processAuthor(String h_data)
	{
	    String[] fields = h_data.split("[,]");
            //и так далее - работа с полями
        }

Видишь? Разбиение строки по запятым и обработка полей происходит уже внутри.

Ну дык, если лексический анализатор мне станет отдавать h_data, то ничего для меня не изменится. Не надо будет ничего переписывать, кроме собственно движка парсера. Вот и все. А то, что ты предлагаешь ведет к переписыванию очень многих вещей... И смысла я не вижу, что самое главное!

Ничего не имею против.

Если решение принято, то написано ли уже правило лексера, которое выбирает строку в скобках с пробелами без изменений?...

Основная потенциальная проблема лишь в том, что одинаковую работу выполняют два разных куска кода. И если один кусок изменить, то другой от этого также может перестать работать. Подобные примеры часто приводятся в качестве ужастиков в книгах по пропаганде ООП (как будто ООП само по себе может устранить зависимость по данным).

Также страшненько выглядят hardcoded имена хендлеров и их независимая отдельная обработка. Нельзя ли что-нибудь обобщить и чтобы похожие действия выполняла только одна функция?

Основная потенциальная проблема лишь в том, что одинаковую работу выполняют два разных куска кода.

Э-э-э... Что-то в этом есть... Но не слишком много. Рассматривай хендлер как функцию, которая принимает на вход один параметр - строку. А уж передать ей эту строку -работа движка парсера.

Также страшненько выглядят hardcoded имена хендлеров и их независимая отдельная обработка.

Хм... Ты во многом прав.
Вообще-то имена хендлеров подключаются reflection и от этого мне не убежать. Не убежать от хардкорных имен... Но, возможно, имеет смысл кое-что переписать...

Если решение принято, то написано ли уже правило лексера, которое выбирает строку в скобках с пробелами без изменений?...


Я все никак не разберусь с правилами регулярок в лексе...
Примерно так:

HANDLER_DATA=		([^\f\t\b\r\n]+)

Ничего больше не буду навязывать...

Когда "истина где то рядом", лучше почитать что-нибудь теоретическое, с целью поиска подходящих идей. Читать можно dragon book, или, например, это:

_http://offline.computerra.ru/2001/402/10900/print.html

(не совсем по теме, но описан один из подходов, как подобные задачи могут решаться "по-научному")

captain cobalt

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