Во-первых, отмечу принципиальное отличие в понимании, что можно говорить Мэтрам, а чего нельзя. Но я останусь на своем мнении, считая Ваше,
Евгений - не адекватным. И, в некотором аспекте, именно Ваше отношение оскорбительно для Мэтров (имеется в виду - настоящих, а не причисляющих себя к таковым), а вовсе не мое.
Но главное не это, а содержательная часть. Поэтому просто приведу некоторые Факты.
Причем, специально отмечу, что этим Фактам совершенно по барабану фамилия Автора, сколько лет он этим занимается, и уж точно, они (Факты) не пойдут перечитывать труды вышеозначенных Авторов.
Они просто ЕСТЬ, и им этого вполне достаточно
1) Существовала себе ОДНА простая сущность: список патернов (токенов) в паре с некими семантическими действиями, которые и определяли семантику токена: либо пропуск, либо результат вместе с некими семантическими значениями, либо (и) смену режима сканирования.
И все. Этой ОДНОЙ сущности хватало для всего. Не было необходимости в магических фразах о невозможности выразить вложенный комментарий через РБНФ. (вообще-то, и сам сканер невозможно выразить ТОЛЬКО через РБНФ)
Но мы отменили (про историю - не знаю, но знаю положение дела именно сейчас) эту ОДНУ, и начали вводить вместо нее много других. Которые ниже и перечислю
2) Для начала, оказывается, у нас все лексемы делятся на два класса: токены и литералы. Ну ладно... хотя чем помешало описание литералов регулярными же выражениями - не очень понятно.
Только одно мне (а Вам ???) в голову приходит - так писать быстрее. А читать ???
А если читать, то оказывается, что литералы (это такая фигня в кавычках) обладают ТРЕМЯ разными семантиками в тексте одного файла. В разделе синтаксиса - это теминал, и есть нечто неделимое (в коде - так просто число). В разделах сканера COMMENTS, TOKENS, PRAGMAS - это регулярное выражение, являющееся конкатенацией входящих в него символов-терминалов. В разделах сканера CHARACTERS, IGNORE - это регулярное выражение, являющееся альтернативой входящих в него символов-терминалов.
И это есть Факт. Он соответствует концепции Оберона, или нет
3) Раздел TOKENS. Отличается от исходного посыла (п.1) тем, что не имеет ни семантического действия, ни возвращаемой величины (аттрибута). Т.е., кто-то лучше разработчика конкретного компилятора знает, что ему это никогда не понадобится. К чему это приводит: да к тому, что семантику, например number, надо будет считать каждый раз при употреблении этого терминала в синтаксисе... В том числе и отгадывать (несколько раз), real это был или integer (хотя это сканеру было прекрасно известно).
Можно конечно... Подумаешь, код будет дублироваться... Только непонятно - зачем же была введена новая сущность, чем старая не устроила-то. У меня была возможность возвращать один и тот же токен (number) для разных патернов с разными семантиками - теперь ее нет. Потому-что таковую возможность некто назвал "пушкой", видимо
4) Раздел COMMENTS. Ну это вообще шедевр:
Цитата:
Comments are difficult to specify with the regular expressions used to denote tokens - indeed, nested comments may not be specified at all in this way
Невозможно, но мы делаем!!!
И скажите нам спасибо.
Вообще-то, невозможно стало именно после отмены п.1. Но, что именно в этом и состоит этот
this way - скромно умалчивается.
5) Раздел IGNORE. Все, что нам можно пропустить - один символ оказывается. Если это будет два или три символа - тогда, наверное, это будет PRAGMA с пустым Action. Окамм в гробу переворачивается, наверное
6) Раздел PRAGMAS. Наверное, это самый близкий раздел к исходной позиции по п.1. Если учесть, что методами хака (RETURN в Action) его можно заставить работать как токен...
7) Очень хотелось бы обратить внимание на служебное слово ANY. Опять разные семантики для сканера и парсера, но посмотрим только на парсер - его семантика и тут зависит от контекста!!! Читаем:
Цитата:
The symbol ANY denotes any terminal that is not an alternative of this ANY symbol
Скажу честно, въехал далеко не с первого раза. А Вы можете перевести данную фразу
Не, не дословно, а чтобы было ПОНЯТНО. В соответствии с продекларированной "прозрачностью" языка. И введена эта
новая сущность для того, чтобы можно было сделать что-то типа такого.
Код:
Attributes < VAR pos, len: LONGINT > =
"<" (. pos := Scanner.pos + 1 .)
{ ANY }
">" (. len := Scanner.pos - pos .) .
Без нее - никак.
Почти комментарий, между прочим... Только, в отличие от комментария, возвращает значение токена и семантику.
И такая возможность ведь была исходно, но ее выкинули, решивши, что пользователю и встроенного комментария будет достаточно.
Про то, чтобы осуществить парсинг "внутренностей" (ну без проблем же было - нужный "Parse" нужного модуля внутри Action) - это же, конечно, никому не нужная "пушка"...
===============================================
Ну вот и все... В принципе, соблюсти принцип Окамма - не есть принципиальное изменение кодов, но требует внимательного обсуждения Постановки Задачи.
Собственно, это верно для любой нетривиальной задачи. Чем нетривиальнее, тем вернее...
И, естественно, не будет обладать обратной совместимостью.
Почему я сказал, что это не по Обероновски. Потому-что к Оберону Вирт прикреплял эпиграф Энштейна: "
Make it as simple as possible, but not simpler"
Ну вот. Если у нас сканер, это устройство по п.1, всего лишь обремененное правилом СДЛ (которое никуда не делось и сегодня), то
сканер - это очень просто.
А если в нем есть ПЯТЬ различных категорий, токены и литералы есть разные сущности, и т.п. -
тогда это немыслимо сложная вещь какая-то. Хоть отдельный курс обучения для него создавай...
А это не есть правда: простая это вещь, сканер, на самом-то деле.
В не зависимости от фамилии проффесора, его создававшего. Простая, и все тут. Гораздо проще, и при этом - более функциональная вещь, чем можно подумать из спецификации на Coco/R
И хоть Вы тут заобижайтесь