Oberon space
General Category => Общий раздел => Тема начата: Berserker от Июнь 06, 2012, 08:07:41 pm
-
Подскажите пожалуйста, где в сообщении о языке "Компонентный Паскаль" регламентируется порядок секций (CONST, TYPE, VAR, PROCEDURE) и их количество. Потому как после первой объявленной процедуры любая другая секция вызывает ошибку.
-
Подскажите пожалуйста, где в сообщении о языке "Компонентный Паскаль" регламентируется порядок секций (CONST, TYPE, VAR, PROCEDURE) и их количество. Потому как после первой объявленной процедуры любая другая секция вызывает ошибку.
Module = MODULE ident ";" [ImportList] DeclSeq [BEGIN StatementSeq] [CLOSE StatementSequence] END ident ".".
ImportList = IMPORT [ident ":="] ident {"," [ident ":="] ident} ";".
DeclSeq = { CONST {ConstDecl ";" } | TYPE {TypeDecl ";"} | VAR {VarDecl ";"}}{ProcDecl ";" | ForwardDecl ";"}.
Если что, собщение о языке в человеческом формате можно посмотреть тут: http://plas.fit.qut.edu.au/gpcp/LanguageReport.aspx
-
Спасибо! Ожидал в описании главы про модули найти.
-
Разве в EBNF знак "|" определяет точную последовательность? Он ведь как оператор ИЛИ.
-
DeclSeq = {CONST {ConstDecl ";" } | TYPE {TypeDecl ";"} | VAR {VarDecl ";"}} {ProcDecl ";" | ForwardDecl ";"}.
можно разбить на три определения так:
DeclSeq = { ConstTypeVarDecl } { ProcForwardDecl }
ConstTypeVarDecl = CONST {ConstDecl ";" } | TYPE {TypeDecl ";"} | VAR {VarDecl ";"}
ProcForwardDecl = ProcDecl ";" | ForwardDecl ";"
Отсюда чётко видно, что сначала должны идти декларации констант, типов, переменных (их можно перемешивать), и только после них можно декларировать процедуры...
-
А вот то, что Вирт вот так вот зашифровал простые вещи -- за это ему жирный минус!
-
А вот то, что Вирт вот так вот зашифровал простые вещи -- за это ему жирный минус!
Зато похоже на него(надо же уложиться в 16 страниц).. :D
-
Разве в EBNF знак "|" определяет точную последовательность? Он ведь как оператор ИЛИ.
Фигурные скобочки означают 0 или более повторений.
Таким образом выделенный кусок правила:
DeclSeq = { CONST {ConstDecl ";" } | TYPE {TypeDecl ";"} | VAR {VarDecl ";"}}{ProcDecl ";" | ForwardDecl ";"}.
означает что например валидна следующая последовательность:
TYPE CONST VAR CONST TYPE TYPE CONST
В общем, блоки CONST, TYPE, VAR чередуются в любой последовательности сколь угодно долго. И да, | - означает выбор альтернативы при каждом повторении выделенного куска правила между {}.
Затем, после того как мы откостились, отварились и оттайпились, вступает в игру вторая половина правила:
DeclSeq = { CONST {ConstDecl ";" } | TYPE {TypeDecl ";"} | VAR {VarDecl ";"}}{ProcDecl ";" | ForwardDecl ";"}.
То есть далее у нас сколь угодно долго и в любом порядке чередуются объявления процедур и forward declaration'ы.
PS. Откровенно говоря, в этом всем нет абсолютно ничего сложного, если конечно немного интересуешься грамматиками. А тот кто не интересуется грамматиками, формальное описание грамматики и не будет читать :-)
-
DeclSeq = {CONST {ConstDecl ";" } | TYPE {TypeDecl ";"} | VAR {VarDecl ";"}} {ProcDecl ";" | ForwardDecl ";"}.
можно разбить на три определения так:
DeclSeq = { ConstTypeVarDecl } { ProcForwardDecl }
ConstTypeVarDecl = CONST {ConstDecl ";" } | TYPE {TypeDecl ";"} | VAR {VarDecl ";"}
ProcForwardDecl = ProcDecl ";" | ForwardDecl ";"
Отсюда чётко видно, что сначала должны идти декларации констант, типов, переменных (их можно перемешивать), и только после них можно декларировать процедуры...
Только отсюда не совсем чётко видно, что разделяющая вертикальная черта определяет и порядок следования элементов CONST, TYPE, VAR.
-
Таким образом выделенный кусок правила:
DeclSeq = { CONST {ConstDecl ";" } | TYPE {TypeDecl ";"} | VAR {VarDecl ";"}}{ProcDecl ";" | ForwardDecl ";"}.
означает что например валидна следующая последовательность:
TYPE CONST VAR CONST TYPE TYPE CONST
В общем, блоки CONST, TYPE, VAR чередуются в любой последовательности сколь угодно долго.
Именно про это и имел в виду. Так что я не ошибся.
-
Таким образом выделенный кусок правила:
DeclSeq = { CONST {ConstDecl ";" } | TYPE {TypeDecl ";"} | VAR {VarDecl ";"}}{ProcDecl ";" | ForwardDecl ";"}.
означает что например валидна следующая последовательность:
TYPE CONST VAR CONST TYPE TYPE CONST
В общем, блоки CONST, TYPE, VAR чередуются в любой последовательности сколь угодно долго.
Именно про это и имел в виду. Так что я не ошибся.
Угу. Порядок следования там любой у CONST, VAR, TYPE. А вот у ConstVarType и ProcDeclFwdDecl - вполне конекретный порядок следования.
-
В общем выходит, что если что-то неясно из словесного описания в сообщении о языке, то объяснение следует искать в его нотации. По крайней мере, в семействе виртовских языков.
-
В общем выходит, что если что-то неясно из словесного описания в сообщении о языке, то объяснение следует искать в его нотации. По крайней мере, в семействе виртовских языков.
Да. Точнее я вначале обычно вообще смотрю грамматику, а уже потом словеску (словеской к формальному описанию добавляются дополнительные ограничения, например если четко следовать только грамматике, то вполне валиден вот такой модуль: MODULE Foo; END Bar.). Для C# например такой подход уже прокатит слабо - там в формальной грамматике есть несколько ошибок (в стандарте).
-
Нормально "краткость сестра таланта" - нет , господа, она порождает танцы вокруг идолища... а что? коровятам самое то!!!
-
Кстати, харе батон крошить на Вирта! Это ж обсуждалась грамматика КП, а не Оберона. В обероне оно так:
module = MODULE ident ";" [ImportList] DeclarationSequence
[BEGIN StatementSequence] END ident "." .
DeclarationSequence = [CONST {ConstDeclaration ";"}]
[TYPE {TypeDeclaration ";"}]
[VAR {VariableDeclaration ";"}]
{ProcedureDeclaration ";"}.
Что как бы сильно проще и читабельней. Правда тут произвольно чередовать TYPE, VAR, CONST уже не выйдет.
-
Только отсюда не совсем чётко видно, что разделяющая вертикальная черта определяет и порядок следования элементов CONST, TYPE, VAR.
А почему отсюда должна быть видна семантика этой вертикальной черты? Обычно это описывается в самом начале, когда описывается, что означают все эти фигурные и квадратные скобки, а так же и эта вертикальная черта.
Всем известно, что эта черта означает неопределённый порядок: CONST или TYPE или VAR в данном случае...
-
Кстати, харе батон крошить на Вирта! Это ж обсуждалась грамматика КП, а не Оберона.
Виртовы ученички обучены Виртом же, значит он виноват в их косяках!!! )))
-
Кстати, харе батон крошить на Вирта! Это ж обсуждалась грамматика КП, а не Оберона.
Виртовы ученички обучены Виртом же, значит он виноват в их косяках!!! )))
да нет в том что им "кушать" хочется виновато "приматное" происхождение :)
-
Тут вот Вирта ругали, а я немного похвалю: у Вирта формальное описание грамматики уже приведено к такому виду, который удобен для реализации парсера (в том числе посредством ручного рекурсивного спуска, или через парсер-комбинаторы, тот же парсек например), в частности из грамматики убраны левые рекурсии. Это дико удобно, не нужно переформулировать грамматику перед реализацией, можно реализовывать сразу. Скажем если взять для сравнения грамматику языка Lua (которая меньше чем обероновская), то перед реализацией парсера придется пройтись по всей грамматике руками вылавливая левую рекурсию и заменяя её на правую (вводя дополнительные нетерминалы там и так далее). Вообще, у меня ощущение сложилось, что грамматика Lua ни разу не LL(k).
Таким образом грамматика языка Оберон ценна не тем, что она маленькая, а тем что она проектировалась с учетом того, что потом еще парсер писать надо будет. То есть она, по моему, даже LL(1), и при этом без левых рекурсий.
Замечу, что для прикладного программиста это конечно все не важно, более того, язык Оберон не изменился бы если бы в грамматике была левая рекурсия (при этом "арифметика синтаксиса" сталa бы лучше чем есть сейчас). Просто изменилась бы трудоемкость реализации утилит работающих с исходниками на Обероне.
-
C другой стороны конечно если ты реализовал парсер для Оберона, это еще не значит что ты умеешь писать парсеры даже для простых и маленьких языков, ибо бОльшую часть граблей Вирт из грамматики Оберона заботливо убрал. Таким образом реализация парсера Оберона не является достаточным упражнением по написанию парсеров в процессе обучения.
-
Поправьте, пожалуйста, название темы. Опечатка вышла.
-
Поправьте, пожалуйста, название темы. Опечатка вышла.
Название конечно поправил, но в ответах тема как была с ошибкой, так и останется.