DRAKON.SU

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

Если вердикт по некоему "улучшителю работы ума" не выносится годами - это и есть однозначный и безоговорочный вердикт. Сравните со скоростью вердикта по Оберону.

В принципе согласен, только некоторые уточнения по пунктам:

О базовом наборе икон (следуя предложению Дмитрия_ВБ, называю их "виопами").
1. Кроме действия, существуют ещё взаимодействия - со внешней средой (ввод/вывод) и с совместно протекающими процессами (в смысле, определённом у Корнеева; в техноязыке принят вызов на рандеву, нужен ещё парный приход на рандеву). Если не считать их базовыми - получается, что алгоритм логически трактуется как "вещь в себе" - то, что это можно описать как действие, трактовки не меняет и сбивает мышление, особенно "предметника". Вот ещё сохранение/извлечение, определённое в этом подпункте, можно трактовать как разновидность действия в базовой структуризации.
3. Не совсем понятно - где Вариант, там ведь и предшествующий Выбор... и "гребёнки", объединяющие варианты... т.е. это не оператор, а макрооператор?
4. Пожалуй, и параметры не стоит исключать из базовых...

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

Когнитивные правила:
"2. Правее - хуже для цели алгоритма.
3. Правее - больше/меньше по какому-то нейтральному к цели алгоритма числовому критерию, который возможно определить для всех маршрутов.
4. Правее - дальше/ближе по некоторому порядку, вводимому для некоего нечислового критерия, сопоставляемого всем маршрутам."
Такая трактовка, IMHO, больше способствует тому, чтобы сочинитель рассуждал о свойствах маршрутов (что поможет и выработке доказательств правильности алгоритма).

Графические правила.
3. Уточнил бы: "..., включая размещение виопов Начало цикла ДЛЯ и Конец цикла ДЛЯ в разных ветках.".
4. "Последняя перед точкой слияния линия (ребро) маршрута, ответвлённого от шампура, может идти назад (приобретая форму, изображённую петлёй цикла)" - иначе получается, что возможно и обратное следование.
5. Если не рассматривать исключения и/или прерывания (визуализированные, напр., как показано в этом подпункте Д2М-определения техноязыка) - то да, конец м.б. один.
8. "...кроме ветки, входящей в веточный цикл и при этом не являющейся его начальной веткой."
10. Если исключения не исключать , то дополняем: "..., завершающей основной визуал (схему), либо, если на этом визуале и/или вставках в него определены исключения/прерывания - оператором Конец (Останов), завершающим исключение/прерывание, если фактически его маршрут приводит к завершению."

Для структурных предложений (кстати, это макрооператоры будут).
1. Циклов много я бы выбрал цикл Дейкстры (в частном случае сводимый к циклу ПОКА).

Ну и расширенный набор соответственно меняется.
Надо думать, в реальной "шпаргалке" не помешает и графика

2 Драконограф: Спасибо за детальный разбор.

Попробуйте записать в текстовом виде Дракон-схему с цепью "действие-проверка-действие-проверка-действие-проверка...", где при неуспехе любой из проверок происходит переход на единый правый путь.

Если IF-ELSE - то получается охренительная вложенность и дублирование в ELSE. И неудобство добавления новых проверок при модификации кода.

Поэтому на практике обычно вводим явно переменную состояния ok: BOOLEAN и пишем:


Но это когда состояния у управляющей системы 2 - нормальное и отказ. А если их несколько? В Драконе каждому состоянию системы управления соответствует колонка схемы. И при проверках условий происходит переход между этими состояниями, сразу видно, в каком мы находимся и куда переходим.

А алгоритмы такой структуры часты в обычной практике - и не только в системном ПО, а как раз в бизнес-логике.

Сравнивать нельзя.

Правильно, сравнивать нельзя. Это разные по назначению вещи.
Они могут дополнять друг друга, и приоритет в последовательности применения у Дракона.

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

Ну да, переменную состояния делаем не булевой, а числовой... или литерной/строковой (имя ветки силуэта, внутри которой (в адресном макроблоке) проверяем условия... или соответственно имя ветви ЦД - тогда условия проверяются в его "шапке", а в ветвях только генерируются состояния)

В качестве составной части умений сочинителя по визуализации формального (в пределе - информатического) понимания задачи можно привести использование РБНФ при графит-представлении знаний. Как пример можно привести такое определение:
Здесь совмещены два способа РБНФ-определения инварианта структуры: чисто визуальный (взятием подструктур в графические скобки) и текстографический (взятием в ограничители с РБНФ-заданием индексов вхождения/перебора), причём для последнего введены ещё два способа индексации: через "итератор (индексатор) необязательности" или "необязательный диапазон индексов" (для i-той строки).
Очевидно, на реальной схеме следует оставлять для конкретной подструктуры один из способов. Каков м.б. критерий выбора? Представляется, что если РБНФ-скобками можно выделить на схеме подструктуры (делая необходимые разрывы связей) при сохранении естественной компоновки схемы - можно пользоваться скобками. Иначе целесообразно брать подструктуры в ограничители (форму которых можно настраивать, что даёт возможность выделить достаточно сложно скомпонованные фрагменты схемы).

Представляется очевидным, что выбрав разделение визуальной структуры на термы и дав им информативные имена, можно описать построение структуры текстовыми РБНФ-выражениями; однако данные о топологии "не один к одному" при этом не будут отражены напрямую - нужно вводить дополнительные средства их описания. По сути эту же задачу - представить текстом матрицу инцидентности/смежности вместе с характеристиками вершин - по-своему решали Рэйлвей Каген (см. вложение в этом сообщении); более ранние результаты также в этом сообщении) и Дмитрий_ВБ (см. вложение в этом сообщении; более ранние результаты также в этом сообщении).

Уточнил некоторые формулировки в исходном сообщении

Ага. Только у меня никогда не было цели написать исчерпывающий справочник по языку. Был поставлен "эксперимент" по решению задач из одной области, руководствуясь правилами из совершенно другой области. Сработало.
Ну, решают же люди нелинейные дифуры через системы линейных алгебраических уравнений.. Что-то вроде этого и здесь

Так именно краткий и нужен для первичного знакомства... Ваша мысль совершенно правильная. Я тоже делал краткую справку по языку (Драконографика по сути является развитием такой справки), только сразу "графит-методом", как я это назвал; по сути во многом он основан на правилах ЕСКД для схем - а в текстовой основе у Вас "сжатие знаний" достигнуто выше, чем у меня - даже если внести все уточнения. Единственное - что и в краткой справке, как в капле воды должны отражаться возможности методологии в целом - исходя из этого и уточнял. Здесь на конференции неоднократно говорили, что хорошо бы определить суть техноязыка "одним абзацем"... что-то подобное Вы и сделали... А графика (точнее, "графит-определения") позволит это показать любому человеку наглядно. И подвести его (в т.ч. на примерах обобщённого изображения структур) к возможности математического вывода схем с учётом текстовой составляющей их содержания (естественно, самим принципам и примерам вывода место в подробном описании - но краткое должно также сочетать графику и текст на схемах)... Лошадь "можно подвести к воде, но нельзя заставить пить", а человека (в данном случае "предметника" с невысокой математической/информатической культурой) нельзя заставить пить - но можно подвести к воде

Да, конечно. Был и второй лист - с картинками: иконы (5+8) и два примера Дракон-схем (в примитиве и в силуэте). Но выступал он лишь в качестве приложения, т.к. собственно правила игры определены в шпаргалке. Задача визуального определения правил не ставилась.

А правила "шампур-садоводства" вообще так сразу визуально не определишь - они же дают произвольные структуры маршрутов. Поэтому и я в этом подразделе остановился только на том, что при выводе даёт "доказательные" структуры...

Один из способов приведён здесь (с.74-75). Попробую предположить, что и с помощью диаграмм Вирта также можно визуально определить синтаксис Дракона.

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

Так что всё там строго и просто определить.

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

Да, я имел в виду именно "нарисовать" эту математическую часть конкретно для операций с лианой по тому же принципу, что в этом сообщении...

Уважаемые коллеги!

Большое спасибо всем, кто принял участие в обсуждении и высказал критические замечания.

Эти замечания представляют огромную ценность для меня.