OberonCore

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

Между тем, синтаксис нетерминалов IdentDef и Qualident относится к классу регулярных выражений, и ни что не мешало придать им статус лексической единицы.

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

Это, между прочим, говорит о том, что комментарий в некоторых местах нужно просто запретить.
А вообще про звездочки я уже возникал... Для С-программера звездочка как красная тряпка-указатель...
Лучше было бы сделать видимость с помощью обычного ключевого слова...

Комментарий и так уже в некоторых местах запрещён . Я имел в виду внутри лексем.
То есть, если бы IdentDef обозначал класс лексем, то между идентификатором и меткой экспорта не то что комментарий, пробел даже нельзя было бы вставить.

А как будет разрешаться неоднозначность на уровне сканера? Работа сканера должна зависеть от контекста? Или требовать обязательно ставить пробелы? Сами и отвечаете на вопрос обоснованности такого усложнения.

P.S.

Да, действительно . Если нетерминал IdentDef возвести в ранг лексем identDef, то РБНФ для начального символа грамматики сканера будет выглядеть так: Такой синтаксис хоть и является регулярным, как я справедливо подметил, но не является детерминированным (вот в чём ошибка!), потому что альтернативы ident и identDef могут иметь одинаковые начальные символы, со всеми вытекающими последствиями.

PS: Должен сказать, что "синий букварь" здорово помогает разобраться во всех этих вопросах

Рассмотрим три конкретных лексемы: число "20", идентификатор "X" и символьную константу "20Х". Вопрос: как сканер умудряется их различать, ведь "20" и "20Х" начинаются одинаково?

Ответ потрясающий, конечно . Дело в том, что он их в первом приближении и не различает вовсе. С точки зрения сканера лексема "20Х" - это тоже число. Но только число, имеющее определённый атрибут (DevCPS.numtyp), уточняющий, что это число является кодом символа.

Сообшение о языке (КП) тоже не врёт: "Лексемы суть идентификаторы, числа, операции и ограничители". Символьной константы в этом списке нет.
Вобщем, всё сходится .

Если говорить о лексике КП, то в сообщении о языке, имхо, не хватает одного правила:
"Между идентификаторами и числами, следующими друг за другом в любом сочетании, должен быть хотя бы один пробел или конец строки ( или символ табуляции)."

Мой сканер многоуровневый, он их различает так. На первом уровне есть понятие последовательности цифр ("20") и последовательности букв ("X"). На следующем уровне, где производится распознавание чисел, ожидается, что за последовательностью цифр может идти буква H, X, E или D, которая и определяет тип числовой константы.

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

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

На входе токены Scanner.ident (последовательность букв) и Scanner.number (последовательность цифр). На выходе токены ScanNumber.hexNumber, ScanNumber.hexChar, ScanNumber.realNumber, ScanNumber.longRealNumber либо ScanNumber.error. Глобальной переменной нет, а идёт преобразование потока токенов от простых к сложным. Соответственно, токены не только могут заменяться, но и их количество на выходе может быть меньше, чем на входе. На самом первом уровне приходят отдельные символы, на последнем - распознанные неделимые сущности. Например, строковые константы, блоки комментариев, цепочки пробелов и т.п. - всё то, внутреннее устройство чего не имеет значения для дальнейшей обработки.

Если после уровня ScanNumber в потоке остался токен Scanner.number, то это может быть только обычное десятичное число без всяких модификаторов. Таким образом, состояние сканера максимально локализовано.Получается, что у меня такие лексемы есть? Интересно, какие это может повлечь последствия?

Сначала, на всякий случай уточню, что термины "токен" и "лексема" являются синонимами. Причём, к термину "токен" тяготеют, имхо, в основном зарубежные спецы.

Вот эта фраза даёт ключ к пониманию. Думаю, что определение "сложный" в данном случае следует трактовать как "состоящий из простых". Похоже, у Вас реализована концепция "суперлексем". Ведь из определения лексем следует, что лексемы не могут внутри себя содержать другие лексемы. Но из того алгоритма, который Вы описали, следует, что некоторые "лексемы на выходе" могут включать в себя несколько "лексем на входе". Вот такие составные лексемы и называются суперлексемами. С точки зрения теории формальных языков эта концепция несколько подмывает фундамент науки. Но на практике это работает . Хм... Есть одна хорошая новость и одна плохая (С) .
Хорошая новость состоит в том, что таблица имён несколько упрощается. В ней теперь не нужно хранить дополнительные атрибуты лексем. Достаточно и самих лексем.
А плохая новость ..., я пока не до конца продумал . Подозреваю, что может возникнуть проблема, на которую указывал Евгений. Я имею в виду необходимость обязательно вставлять пробелы между определёнными классами лексем. Впрочем, этот вопрос пока остаётся открытым. (Время третий час ночи. Спать пора! )

Удивляюсь я на Вас.... То у Вас заморочки в C-шных неравенствах, то как отличить числовые лексемы

Как различает ??? Да он устроен так, этот лексер !!!
Принимает самую длинную лексему - это он устроен так, по определению. Любой лексер. И никаких проблем с этим ни у каких лексеров не возникает. И не возникало никогда.

Какой ещё "любой лексер"? Лично я обсуждаю отличия устройства моего лексера ( viewtopic.php?f=30&t=2205 ) от описанного в книге "Построение компиляторов" Н.Вирта (он же используется в ОС Oberon и компиляторе BlackBox).

- Папа, а как устроен мозг?
- Отстань, сынок, у меня голова другим забита!

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

Вывод: ирония была крайне неуместна

Или что, надо две страницы разъяснять, что "20X" более длинная лексема, чем "20"

Вопрос как раз и состоит в том, что считать лексемой, и как оно должно или может работать.Для моего сканера "20" и "X" - это две разные лексемы, которые объединяются только при определённых условиях.

Вот и я говорю - офигеть можно от глубины вопроса
Так же, как и от разборок с неравенствами

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

Спасибо за сочувствие. И за вклад в обсуждение, конечно же! Мы приближаемся к обещанной вами второй странице.

А я вполне серьезно, между прочим.
Есть ОПРЕДЕЛЕНИЯ в лексике, синтаксисе, ну и в семантике в какой-то степени.
И начинается обсуждение, как следует понимать эти определения - дурдом ведь.
Чего там обсуждать - понимать как написано. Это написанное, даже тупой компьютер понимает.

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