OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 21:21

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 46 ]  На страницу 1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Coco/R
СообщениеДобавлено: Четверг, 11 Март, 2010 15:34 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Добрался до "посмотреть" Coco/R, как и обещал Евгению.
Блин, дык ведь там же все уже написано :!: про формализм определения сканера (+ парсера, для исключения нестыковок)

Первый раз я давненько (за Оберон и не слышал в то время) с ним сталкивался, и у меня был Дельфячий вариант...
А сейчас смотрю - так ведь его "щвейцарцы" и состряпали !!!
И Оберон там есть...
Правда в каком-то странном виде: "this version is not further developed and differs from the C# and Java versions. It is also non-reentrant"... Чего оно, эти "щвейцарцы", себе позволяют - не пойму...
И фиг его знает чем разархивировать ихний .cod... Никто случайно не знает ???


Вложения:
coco_report.pdf [185.22 КБ]
Скачиваний: 1026
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Март, 2010 15:46 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Порт для ББ: http://www.zinnamturm.eu/downloadsAC.htm#Coco


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Март, 2010 17:01 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
И чем открывать этот, теперь уже .pac :(


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Март, 2010 17:32 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Открывать .pac вот этим:

http://www.zinnamturm.eu/downloadsOS.htm#Pac

Цитата:
How to decode PacCoded File?
download the Subsystem Pac, read Quick-Start and follow the instruction to install it.
use the menu [File][Open], choose file type PACed (*.pac) and open the xxx.pac file.
press the command button "Unpack all".
read the document "xxx/Docu/Quick-Start.odc".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Март, 2010 19:24 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Galkov писал(а):
И чем открывать этот, теперь уже .pac :(
Но там же Std есть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Март, 2010 20:26 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Да, спасибо.
Пришлось догадаться (для меня все это в новость) :)
Поскольку компиляция-то не идет (кажется, "синоним иммпорта" не работает...)


Последний раз редактировалось Galkov Четверг, 11 Март, 2010 21:41, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Март, 2010 21:37 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Хм...

И все-таки, Coco/R - "подрезан", по сравнению с Flex (синтаксическую часть пока с Бизоном сравнивать не будем - разные кухни)
Скажем, мне совершенно понятно, как в Flex сделать вложенные комментарии разных типов (ну скажем, плюс к (*......*) - добавить /*.......*/, и все вместе взаимо-вложенное)
А в CocoR - нет. В смысле, мне кажется, что и не сделаешь...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Март, 2010 21:45 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
не сделаешь... а оно надо?

Где-то в описании Coco/R говорилось почему он "подрезан". Что-то типа "не стрелять из пушки по воробьям"...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2010 00:24 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Про "пушку"... Это больше похоже на высокопарные слова, прикрывающие Неумение.
Решать, что есть "пушка", а что "воробей" - это прерогатива Автора компилятора (он же - пользователь компилятора компиляторов)
А дело Авторов компилятора компиляторов - предоставить возможность сделать таковые выборы.
При этом, этот метаязык (а не результат работы Coco) должен быть минимальным, надежным, адекватным, прозрачным, и т.д..
Вот об этом пусть и думают. И не надо быть святее Папы Римского. Каждый должен висеть за свое яйцо...

Смысл же не конкретно в комментарии, а в том, что сканер может (имеет право, теоретически) содержать в себе функциональность радикально менять свое поведение (вплоть до переключения с одного языка на другой). Не меняя при этом своего конечно-автоматного содержания.

Проблемы тут гносеологического характера у них, наверное.
Хоть бери, и достраивай :D

P.S. Кстати говоря, если из Flex откинуть весь "синтаксический сахар", а оставить только концептуальные вещи (как бы акцентироваться на свойстве минимальности), то будет более компактная и прозрачная схема, чем в Coco. Не, не по обероновски это :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2010 09:49 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Galkov писал(а):
Решать, что есть "пушка", а что "воробей" - это прерогатива Автора компилятора (он же - пользователь компилятора компиляторов)
А дело Авторов компилятора компиляторов - предоставить возможность сделать таковые выборы.
Автор компилятора компиляторов X прежде всего сам Автор компилятора -- как минимум --- X. По-обероновски, если X сам себя создаёт.

Если некто будет делать X без разработки на нём реальных компиляторов, то такому инструменту, по-моему, место только на помойке.
Galkov писал(а):
Про "пушку"... Это больше похоже на высокопарные слова, прикрывающие Неумение.
Так что до того, как делать выводы, думаю Вам стоит подробно ознакомиться с результатами исследований Автора компиляторов и Автора компилятора компиляторов -- Хаспенсера Мёссенбока. Он же автор Coco/R.

В Coco/R для ББ они лежат в Coco/Docu: Coco-Paper.ps и Coco-Report.ps

P.S. Как найду способ выковырять из .ps текст, процитирую, на мой взгляд важное, тут ...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2010 10:03 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
про "высокопарные слова, прикрывающие Неумение." Coco-Paper.ps
Hanspeter Mo"ssenbo"ck писал(а):
Abstract
This paper presents a compiler description language and its implementation Coco/R (Compiler Compiler for Recursive Descent). Coco/R reads an attributed EBNF grammar of a language and translates it into a recursive descent parser and a scanner for that language. The programmer has to supply a main program that calls the parser and semantic modules that are called from within the parser. Coco/R evolved from two predecessors: the scanner generator Alex [Mo"ss86] and the parser generator Coco [ReMo"89]. Their input languages were merged and simplified due to our experiences with these tools over several years (a similar tool with a slightly different motivation also emerged from Alex and Coco [DoPi90]). Using Coco/R, compilers can be generated that are as efficient as hand-coded and carefully optimized production quality compilers. Almost as important as efficiency is the simplicity and adequacy of the system. Programmers are not willing to use a tool if it does not come in handy to their work, if it uses an arcane notation or a bulk of options and special cases. Coco/R puts simplicity and efficiency over power.

Hanspeter Mo"ssenbo"ck писал(а):
1. INTRODUCTION
Sometimes the most simple techniques are also the most efficient ones. While hand-written compilers usually are implemented in recursive descent, most of the generated compilers use table-driven LL(1) or LALR(1) techniques. After experiences with several parsing methods [Mo"ss87] I returned to recursive descent parsing since I believe that there is hardly anything so efficient, and at the same time so convenient, as this technique. Its advantages are:
  • No table access. For table-driven parsers to be space-efficient the tables have to be compressed and accessing them needs decoding. In recursive descent parsing, recognizing the current symbol requires only a simple comparison.
  • Easy semantic evaluation. Semantic actions are embedded directly into the parser and do not have to be collected into a procedure that is called whenever an action is to be executed. Every production corresponds to a parsing procedure with its own scope for local variables.
  • Transparency. Recursive descent parsers can be read and understood while the tables of a table-driven parser remain a mystery for the programmer.
  • Controlling the parser. Since parsing and semantic analysis are intertwined so closely one can control the parser from the semantic actions. This makes it possible to parse languages whose grammars are not LL(1).
  • Adequate parser size. Table-driven parsers are usually smaller than recursive descent
    parsers. However, while their size is nearly the same for both small and large grammars, the size of a recursive descent parser depends on the size of the grammar. For small grammars a recursive descent parser is probably smaller than a table-driven parser.
One of the major problems with recursive descent parsing is that sophisticated error-handling is harder to implement than for table-driven parsers. The error-handling technique presented in Section 5 attacks this problem.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2010 10:13 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Про "из пушки по воробьям", Coco-Paper.ps
Hanspeter Mo"ssenbo"ck писал(а):
7. CONCLUSION

The field of compiler construction and compiler generation has long become mature. Various methods of scanning, parsing and semantic evaluation have been studied extensively. Time has come now to make good use of that knowledge and to design tools that are as simple and as efficient as we can achieve today. Coco/R is an effort in this direction. It is definitely not a prototype but a production quality tool with simplicity and efficiency as a major design goal.

A simple tool should be based on a familiar notation, it should require as little input as possible and its function should be transparent and predictable to its user. For the generated parts to be able to compete with production quality compilers they must be small and fast. This can be achieved by using single-pass compilation with semantic actions executed during parsing, by burning the grammar into code instead of using table-driven techniques and by using efficient error-handling that does not slow down error-free parsing. For many translation tasks, such as the processing of small command languages, this kind of compilation scheme is quite sufficient (more powerful schemes would even be an overkill) and also proper compilers for many real programming languages such as Modula-2 or Oberon do not require heavier guns.

Coco/R matches the above requirements to a large degree. The compilers generated by it are comparable to hand-written compilers both in speed and in size. The input language Cocol/R is easy to learn since it is small and based on familiar concepts (EBNF grammars and a general purpose programming language). A compiler description in Cocol/R is about half the size of the compiler parts generated from it. It provides a better overview of the syntactic and semantic activities in a compiler and is therefore more readable.

Let me conclude with a personal remark: Many compiler generating systems strive for power instead of simplicity and efficiency. I believe that this has done harm to the design of programming languages. The power of compiler generators may well have encouraged the complexity of some of today's languages. Are such powerful tools really necessary? I believe they are not. For me, there seems to be little reason why a programming language should not be designed in a way that makes it amenable to single-pass compilation and top-down parsing


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2010 10:24 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Про комментарии (Разве такого механизма мало?), Coco-Report.ps
Hanspeter Mo"ssenbo"ck писал(а):
Comments. Comments are difficult (nested comments are even impossible) to specify with regular expressions. This makes it necessary to have a special construct to express their structure. Comments are declared by specifying their opening and their closing brackets. It is possible to declare several kinds of comments. Comment brackets must not be longer than 2 characters.
Код:
CommentDecl = "COMMENTS" "FROM" TokenExpr "TO" TokenExpr ["NESTED"].
Examples
Код:
COMMENTS FROM "(*" TO "*)" NESTED
COMMENTS FROM "--" TO eol



Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2010 10:35 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Про сканер (если встроенного механизма комментариев или чего ещё -- мало) и вообще про "прерогативу Автора компилятора", Coco-Report.ps (подчёркивание моё)
Hanspeter Mo"ssenbo"ck писал(а):
4. Hints for Advanced Users of Coco/R
Providing a Hand-Written Scanner Scanning is a time-consuming task.
The scanner generated by Coco/R is optimized, but it is implemented as a deterministic finite automaton, which introduces some overhead. A manual implementation of the scanner is slightly more efficient. For time-critical applications a programmer may want to generate a parser but provide a hand-written scanner. This can be done by declaring all terminal symbols (including literals) as tokens but without defining their structure by an EBNF expression, e.g.,
Код:
TOKENS
  ident
  number
  "IF"
  ...
If a named token is declared without structure, no scanner is generated...

Tailoring the Generated Compiler Parts to One's Needs
Using a generator usually increases productivity while at the same time flexibility is decreased. There are always special cases that can be handled more efficiently in a hand-written implementation. A good tool handles routine matters in a standard way but gives the user the chance to change them if he wants to. Coco/R generates the scanner and the parser from source texts (so-called frames) stored under the names Scanner.FRM and Parser.FRM. It does so by inserting grammar-specific parts into these frames. The programmer may edit the frames and may therefore change any of the internally used algorithms. For example, he can Implement a different buffering scheme for input characters

...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 16 Март, 2010 17:00 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Во-первых, отмечу принципиальное отличие в понимании, что можно говорить Мэтрам, а чего нельзя. Но я останусь на своем мнении, считая Ваше, Евгений - не адекватным. И, в некотором аспекте, именно Ваше отношение оскорбительно для Мэтров (имеется в виду - настоящих, а не причисляющих себя к таковым), а вовсе не мое.

Но главное не это, а содержательная часть. Поэтому просто приведу некоторые Факты.
Причем, специально отмечу, что этим Фактам совершенно по барабану фамилия Автора, сколько лет он этим занимается, и уж точно, они (Факты) не пойдут перечитывать труды вышеозначенных Авторов.
Они просто ЕСТЬ, и им этого вполне достаточно :)

1) Существовала себе ОДНА простая сущность: список патернов (токенов) в паре с некими семантическими действиями, которые и определяли семантику токена: либо пропуск, либо результат вместе с некими семантическими значениями, либо (и) смену режима сканирования.
И все. Этой ОДНОЙ сущности хватало для всего. Не было необходимости в магических фразах о невозможности выразить вложенный комментарий через РБНФ. (вообще-то, и сам сканер невозможно выразить ТОЛЬКО через РБНФ)

Но мы отменили (про историю - не знаю, но знаю положение дела именно сейчас) эту ОДНУ, и начали вводить вместо нее много других. Которые ниже и перечислю :wink:

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
Невозможно, но мы делаем!!!
И скажите нам спасибо. :lol:
Вообще-то, невозможно стало именно после отмены п.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
И хоть Вы тут заобижайтесь :lol:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 16 Март, 2010 18:45 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 563
Откуда: Москва
Несколько сумбурно изложено, трудно читать.
Galkov писал(а):
1) Существовала себе ОДНА простая сущность...
Где и когда она существовала, хорошо привести бы ссылки.
Galkov писал(а):
Но мы отменили (про историю - не знаю, но знаю положение дела именно сейчас) эту ОДНУ, и начали вводить вместо нее много других.
Кто - мы?

Вообще-то, если есть критика, хорошо бы привести альтернативу: вот, типа, решение в котором нет указанных недостатков, возможности не меньше, примеры прилагаются.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 17 Март, 2010 16:16 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Peter Almazov писал(а):
Несколько сумбурно изложено, трудно читать
Ну возможно...
Дык: на любой Ваш вопрос - любой наш ответ

Peter Almazov писал(а):
Где и когда она существовала, хорошо привести бы ссылки
Всегда существовала. На то она и "сущность", что для существования ей нет необходимости в наличии ссылок.
Нет у меня ссылок.
Не виноват я в том, что все Великие пишут, что сканер нужен не более, чем для удобства.
А это неправда: он нужен для ликвидации неоднозначности разбиения исходного текста на лексемы. И ссылок на это у меня нет.
И на правило СДЛ нет у меня ссылок, что оно применяется всегда и везде (и в Coco - в том числе). Но оно применяется. Про него вообще, только у дядющки АхО упоминание вскользь есть, при описании конкретного инструмента LEX.

Соглашусь, с падежами у меня проблемы... Не только "существовала", но и сейчас живет и здравствует.
Например, когда Вы, Peter, писали: com = cbeg {char|com} cend - "она" тоже существовала (btw: к вопросу "Кто - мы").
Что сие означает? Означает то, что что сканер, по принятии лексемы cbeg, переключается в иной режим, в котором принимаются только (в отличие от основного режима) лексемы cbeg, char, cend. И никаких других! По принятию последней - возвращается в основной (семантическое действие).
Ну или по другому (если уж очень хочется применить кс-грамматику): семантическим действием лексемы cbeg является вызов парсера выражения com1 = {char|(cbeg com1)} cend, использующего свой сканер с набором лексем лишь - cbeg, char, cend.
Суть не меняется... Просто и парсер и сканер можно заоптимизировать в одну (например) рекурсивную процедуру...
ВСЕ, никакой магии с новыми сущностями COMMENTS, ANY, PRAGMAS, IGNORE, и иже с ними
Без вопросов типа: "а надо ли это"
Что надо-то, если оно уже было. Более правомерен другой вопрос: "а надо ли было ломать основную концепцию?"

Какая концепция - сто раз уже в этом топике писал, вроде бы... Повторю (в смысле, попытаюсь еще раз сформулировать):
  1. Сканер определяется списком патернов (регулярных выражений), каждый в паре со своим семантическим действием (возможно пустым).
  2. Каждый патерн имеет принадлежность некому стартовому состоянию(ям)
  3. Всегда срабатывает только одно семантическое действие - по правилу СДЛ (и никакому другому!!!). Если длины лексем для разных патернов одинаковые - для первого из них (самых длинных) в вышеозначенном списке. Дальнейшее поведение сканера (возврат токена, выбор следующей лексемы, смена стартового состояния) определяется именно этим семантическим действием.
  4. Следующая лексема (после выполнения одной из семантик) начинает проверяться на соответствие только патернам, принадлежащим текущему стартовому состоянию. Которое может быть изменено/установлено предыдущим семантическим действием
Вот так устроены ВСЕ сканеры. Даже если об этом не написано. Например, любая из "сущностей" в Coco/R - частная реализация этой одной концепции.
Ссылок у меня нет, но lex-формализм описывает все из этой концепции. Плюс - куча синтаксического сахара.
Фактически, с моей стороны, лишь выкинуто из lex все несущественное (Make it as simple as possible)
Но "много разных стартовых состояний" я выкинуть не могу (but not simpler), даже если это могут позволить себе Мэтры. Дико извиняюсь, конечно же, но у меня и своя голова есть.
Но зато я могу позволить себе посмотреть (проанализировать) результаты такого выкидывания
О чем и доложил вышестоящим постом :)


Peter Almazov писал(а):
Вообще-то, если есть критика, хорошо бы привести альтернативу
Вообще-то, критиковать я не собирался.
А собирался лишь привести факты, подтверждающие объективность утверждения о "неОбероновости" конкретного софта.
И сразу же кого-то обидел :wink:
Вообще-то, интересно получается...
Сказал, что сканер устроен очень просто - обиделись.
Сказал, что лексика Оберона недетерминирована - обиделись.
Не Обероновский подход в Coco/R - тоже обиделись.
Типа это моя вина, что именно так и происходит на самом деле...
Давно хочу сказать, что и синтасис Оберона в LL(1) не лезет - уже и боюсь говорить ведь
Но - УРА :!: Теперь у меня есть ссылка на проффесора Mössenböck, который говорит тоже самое. Вот ведь что главное на форуме - ссылку на Мэтра найти.
Ощущение такое складывается, что на форуме не технические вопросы обсуждают, а защищают Мэтров от неких нападок неких невежд... Эдакая священная миссия...

Альтернативы... Как я уже сказал, ничего нового, имеющегося в реальном LEX-формализме я не обнаружил.
Но там не Виртовский синтаксис, и супер заточка под C, а вовсе не под Оберон. И генерируемые файлы - под 1500 строк.
((btw: Вот ведь загадка природы - чем можно заниматься в на таком объеме кода, для такой простой задачи, как сканер :D ))

Конкретно для Оберона... Ну вот он - Coco/R. Альтернатива - взять и переделать ему front-end. Не взирая на лица. Но это еще никто не сделал. А чтобы сделать, мне представляется логичным, этот новый (иной) front-end очень внимательно обсудить. Утрясти вопросы "Обероновости"... Ну хорошо, пусть будет - Энштейна :)
Уж и не знаю, получится ли... Это же не Мэтров от нападок защищать :D
Кому как, а мне, ожидание сюрпризов (непреодолимых in this way) от написания какого-нибудь a := "(*)" в какой-нибудь семантике - не нравится.


Последний раз редактировалось Galkov Понедельник, 22 Март, 2010 00:34, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 17 Март, 2010 16:39 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 563
Откуда: Москва
Так и хочется поспорить, но не с чем.
Согласен практически со всем :)
И мэтров я не защищаю...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 17 Март, 2010 19:36 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Galkov писал(а):
Ощущение такое складывается, что на форуме не технические вопросы обсуждают, а защищают Мэтров от неких нападок неких невежд... Эдакая священная миссия...


Да ну, последний год такого не замечено. Не помню даже фраз типа "а вот Вирт...".
Просто Вы рассуждаете достаточно "ортогонально" и самобытно, многим трудно поспевать. Срабатывает обычный гомеостаз проф. общности.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 17 Март, 2010 21:58 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Galkov писал(а):
А собирался лишь привести факты, подтверждающие объективность утверждения о "неОбероновости" конкретного софта
Насчёт "неОбероновости" не убедили. На мой взгляд в Ваших рассуждениях есть два изъяна:
1) Вы сравниваете специально "подрезанный" Coco/R с более мощным построителем сканеров flex.
2) Забываете
Galkov писал(а):
И все-таки, Coco/R - "подрезан", по сравнению с Flex (синтаксическую часть пока с Бизоном сравнивать не будем - разные кухни)
что по сложности надо сравнивать Coco/R со связкой, например, flex+bison.

Пока я останусь согласен с Мёссенбоком (моим пониманием его текста)
1) Заявлена конкретная ниша:
Цитата:
For many translation tasks, such as the processing of small command languages, this kind of compilation scheme is quite sufficient (more powerful schemes would even be an overkill) and also proper compilers for many real programming languages such as Modula-2 or Oberon do not require heavier guns.
2) Для неё сделан более простой инструмент
Цитата:
Coco/R evolved from two predecessors: the scanner generator Alex [Mo"ss86] and the parser generator Coco [ReMo"89]. Their input languages were merged and simplified due to our experiences with these tools over several years
Для тех простых языков, которые можно описать на Coco/R мы получаем сразу и сканер и парсер. Это, по заявлянию Мёссенбока, легче, нежели использование двух более мощных инструментов для генерации отдельных сканера и парсера и их последующего сращивания. Т. е. оправдывает введение описанных Вами дополнительных сущностей.

Согласен с Peter Almazov, что сравнение, дополненное примерами, было бы очень кстати. Т.е. взять язык (для которого средств Coco/R достаточно) и сравнить решения на Coco/R и flex+bison...


Galkov писал(а):
Вообще-то, критиковать я не собирался... И сразу же кого-то обидел :wink:
На высказывание
Galkov писал(а):
Про "пушку"... Это больше похоже на высокопарные слова, прикрывающие Неумение.
было предложено "подробно ознакомиться с результатами исследований" "до того, как делать выводы". Неверно априори считать неумелым человека, работающего в данной области много лет. :wink:


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 46 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB