DRAKON.SU

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



Возможности:
1. ДРАКОН -> ПРОТОН -> исходный код
2. исходный код -> ПРОТОН -> ДРАКОН
3. ПРОТОН -> AST(abstract syntax tree)

По последнему для BlackBox есть конкретные предложения:

Btw, хотя и не в тему, заметил в примере странную неоднозначность: (зелёный, ИНАЧЕ, жёлтый, красный).
Любой нормальный человек (ИМХО) будет читать слева направо, и поймёт ИНАЧЕ как "всё остальное, кроме зелёного". Тогда с какого перепугу дальше следуют жёлтый и красный?!

После минутного размышления становится понятно, что на самом деле ИНАЧЕ означает "всё, кроме зелёного, жёлтого и красного", просто порядок выбора перетасован для удобства ИЗОБРАЖЕНИЯ последующей схемы (кстати же, не могу не заметить ядовито, что паронджановское правило "чем хуже, тем правее" здесь нарушено!).

А как, пардон, компилировать такой гнусный пример? Особенно в свете того, что все привыкли минимизировать вычисление логических выражений, и тогда напрашивается последовательная проверка слева направо, и компилятор требуется двухпроходный, чтобы узнать заранее, что такое есть ИНАЧЕ.

Итого, данное применение ИНАЧЕ:
- для человека - неэргономично (когнитивное противоречие);
- для компилятора - затратно.

"Press any key to continue, other key to exit" :)

1. "Гнусный", но структурный по Дракон'у пример выбран для демонстрации возможностей структурной записи с использованием ПРОТОН. Похоже, что записать такое структурными конструкциями Oberon, CP или C без повторов будет затруднительно. Я не призываю заниматься "экстремальным" программированием, но если предлОжите красивую небольшую схемку - оформлю ещё один пример. Насчёт ядовитости - категорически не согласен. Всё, что в Драконе не имеет структурных ошибок, надо иметь возможность записать/сохранить/показать/проанализировать/скомпилировать. Когнитивные ошибки(не выполняется "чем правее-тем хуже") - это совсем иной слой. S-выражений для работы с ним явно недостаточно Но самое интересное, что Дракон-схема с когнитивными ошибками уже прекрасно скомпилируется.
2. ПРОТОН - нечеловекочитаемое, нечеловекопонимаемое и т.д.. Эта штука для промежуточного представления программ и алгоритмов. А именно - для хранения(cvs..), распространения, трансляции в синтаксическое дерево(если текст в кавычках на Oberon, CP, C..). По сути - прокладка между текстовым/графическим редактором и front-end компилятора. Последний же весьма упрощается, поскольку на вход получит "почти" расцикленное представление.
3. "иначе" - всего лишь одна из констант тернарной логики. По некоторым соображениям, реализация "case..else" менее выгодна, чем сравнение с образцом, пусть даже факторизованное.

Не понял, какая связь... Причём тут тернарная логика? Можно на данном примере подробнее?

Алексей, Вы саму нотацию-то хоть глянули? Она нетипизованная. И "pattern matching" выглядит (именно выглядит! Вы же сами учили!) для записи как отдельные сравнения. Поэтому без разницы, с чем сопоставлять светофор - с "красным", "зелёным", "синим", "true", "false", "else" или "мягким".

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

Может быть надо переименовать "иначе" в "любой" (otherwise), "неопределённый" (undefined)? тогда не будет путаницы с программистским "если-то-иначе"...

И, кстати, в примере этот "иначе" логичнее объединить с "зелёный"...

ЗЫ. Возможно, S-expressions -- не самая подходящая структура данных для хранения дракон-диаграммы, ведь она по сути -- дерево, а эти диаграмы совсем не древовидны. Придётся как-то помечать некоторые узлы и указывать goto на них...

1. если переименовать. то будет путаница с матлогикой. У всех. А так - 50/50. Часть народа легко воспримет "иначе" как константу логического типа. А вторая часть - привыкнет.
2. Светофор может и не гореть вовсе или гореть как-то странно. Всёж-таки технический девайс.. Поэтому объединять не надо.
3. Вроде R-exp - деревья, а S-exp - списки. По моему, Дракон-программа в общем случае - это список деревье. Насчёт R-exp - обеими руками "за" на этапе трансляции и далее. А дерево из ПРОТОН можно получить уже на "примитиве" и "ветке" за счёт развязки от goto с помощью структурных JOIN/INNER_JOIN/JOINED. Драконовский силуэт можно рассматривать как вызов процедур(веток) без параметров, соответственно - без goto. Но последнее - осторожно.

p.s.: в п.3 R-exp для трансляции - из соображений более удобного перемещения по дереву(имхо). S-exp для редактирования - область видимости элементов определена сразу же.

Что такое "константа логического типа" в данном случае? Как она выглядит с алгоритмической точки зрения? Достали уже математики, оторванные от реальности!

Предположим, что "светофор" - это переменная (для определённости).

1. Мне плевать на внутренности, я пользователь. И я знаю, чего хочу:
- я должен наглядно видеть множество возможных значений "светофора";
- я должен быть уверен, что среда программирования обеспечит мне полноту рассмотрения этого множества.

Что имеем в данном примере?
- множество не определено полностью, так как состояний светофора может быть бесчисленное количество;
- полнота рассмотрения достигается кривым путём при помощи т.н. "паттерна" "ИНАЧЕ", кторый покрывает весь диапазон возможных значений, не определённых изначально;

Итого: с этим можно согласиться, если такой wildcard будет стоять в алгоритмически определённом месте (после всех более конкретных паттернов). Однако в примере он стоит в середине списка (да и список как таковой выделен не очень наглядно - всё-таки блок-схема). Следовательно, я обязан чётко представлять, каким именно образом в системе реализован этот самый pattern matching. Причём в большинстве известных мне случаев имеет место тупой последовательный перебор паттернов, пока не будет найден первый подходящий (а им будет ИНАЧЕ, и до жёлтого с красным дело никогда не дойдёт).

2. Я - разработчик компилятора. Я реализую pattern matching, как мне удобнее (или как считаю нужным), и мне пофиг проблемы юзера, который сам не знает, чего хочет.

Круг замкнулся.

Кажется, вот так лучше:

как вариант - нормальный компилер определит "else" как отрицание набора высказываний в том месте, где используется "хрен_его_знает_как_он_там_горит". И круги нарезать не потребуется.

Разумеется, это не определение, а трактовка.

Сказать честно? Лучше не стало.

Попробуйте модифицировать алгоритм. К примеру, ввести обработку состояний "мигающий зелёный" и "жёлтый одновременно с красным".

Сейчас мне уже начинает казаться, что задача разложения сложного графа на плоскость без пересечений в общем случае неразрешима.

Соответственно, в топку правило Паронджанова "чем хуже, тем правее", в топку также шампур.
Ну, шампур ещё как-то можно сохранить за счёт оверхеда - дублирующихся развилок и т.п. Что не есть гут.

Ау, Геннадий - Вы любите разрисовывать учебные примеры, попробуйте - вдруг получится?

И ещё Илью хотелось бы услышать!

В книге "Почему мудрец похож на обезьяну.." есть главы "Что делать. если принцип "чем правее, тем хуже" не работает?" и "Как рисовать побочные маршруты7", а в электронной версии "Как улучшить работу ума.." есть глава "Что делать, если эргономические правила противоречат друг другу?".
Рецепты:
расстановка приоритетов
упорядочение не с помощью "хуже", а с помощью "чисел"
формирование новых правил
выбор наилучшего правила

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

Дык, у нас тогда все реальные случаи экстремальными станут.
Нет, тут что-то в консерватории не то!
Вопрос вообще в возможности развёртывания сложного графа на плоскости с учётом ограничений.

Илья может сказать - не делайте сложные графы. Хотелось бы

Хи, хи!
Кто-то тут математиков костерил... А вопрос-то ставится теоретический

На практике получается, что графические правила ДРАКОНа гарантируют, что маршруты переходов будут либо обособленными, либо вложенными. Это без Эйлера и специфических укладок. Так что в консерватории - порядок.

Возможно, что так. Мне трудно судить об этом - не математик
Было бы интересно увидеть пример в развитии (как писал выше - мигающий зелёный, жёлтый вместе с красным). Так результаты сложной теории станут понятны многим, надеюсь

И я не математик.

Что касается примера, то нужна именно красивая, компактная схема, бесспорная с когнитивной точки зрения. Навскидку что-то ничего в голову не приходит. Развивать экстремальный светофор? А нужно ли? Это вроде Duff's device, не более того.

Не, ну Вы ж говорите, что всегда можно развернуть. Ну покажите на конкретном примере

Ну говорил. Только для других поверхностей укладки. ПРОТОН - не для них.

Записать модифицированную Дракон-схему светофора в ПРОТОН - не вопрос. Вы готовы доработать необходимую Дракон-схему? Вот исходник:

Дык, как раз дракон-схема и интересна

Чем? Я выбрал её для примера по следующим соображениям

Вы предлагаете добавить ещё пару состояний светофора и действия по их обработке. Но в итоге будете вынуждены следовать правилам Дракона для изображения модифицированного алгоритма. Схема всё равно останется структурной и сможет быть записана в ПРОТОН. Но нового знания ни Вы, ни собеседники не получат.