DRAKON.SU

По результатам обсуждения я сделал следующий вывод относительно моей книги


Вывод. В этой книге страницы 353—356 являются неудовлетворительными и должны быть заново отредактированы. Я намерен сделать это при переиздании.

Да, это хорошо. Ибо давно назрела необходимость показать, что ДРАКОН как маршрут-нотация, претендующая на универсальность, должен здесь находиться (и по факту находится) «над схваткой». То есть, соответствуя ВП:НТЗ, предоставлять средства выражения структуры как с явными БП, так и без них.
Имеется в виду следующее. При размещении в информационном пространстве исполнителя нелинейная (а при определённых условиях — и линейная) структура требует разрывов между некоторыми линейными её участками. Что означает невозможность естественного перехода к следующему элементу структуры. Для указания следующего элемента в этом случае и служит БП. С позиций структурности, следует различать случаи безусловного перехода в период сочинения:

* явный — вводимый по желанию сочинителя на указанную им метку;
* неявный — требуемый маршрутной структурой алгоритма при её выкладке — размещении на «ленте памяти»;

Термины здесь мои и м.б. изменены. Для исполнения также м.б. введены БП с другими целями (напр., для размещения в сегментированном пространстве) - но это к данному вопросу не относится.

В исходном определении эта «нейтральность» не прослеживается. Есть выразительные средства для явных БП при укладке маршрутного графа без пересечений (силуэт), но нет — для укладки без явных БП (имеется примитив, где потенциально можно избежать пересечений — если исключить операции с лианой — но нет средств структурировать целиком алгоритм, как в силуэте). Тогда как классическое структурное программирование предоставляет такие средства в рамках метода Дейкстры. Дело только за их визуализацией — поскольку изначально они определялись в чисто текстовой форме.
Более того, в ВП-статье в п. «Гибридные языки ДРАКОН-семейства и оператор GOTO» утверждается о желательности goto — что однозначно не-нейтрально и противоречит позиции об универсальности ДРАКОНа как маршрутной нотации и об унификации с его помощью граф-представления маршрутной части неопределённого круга прогязыков.

В "Как улучшить..." прослеживается возможная причина этого - смешение выразительных средств для управляющих знаний (в разных формах записи) и понятий, которые за ними стоят (независимо от формы записи). И сказанное на с. 264: - нуждается в корректировке.

Во-первых - goto не относится к структурному программированию (неважно, в какой форме). Его применение и есть признак отхода от структурности. Так что в текстовом варианте понятие, выражаемое этим словом, тоже не используется...

Во-вторых - за goto стоит понятие явного БП (на метку, определяемую сочинителем). И в графической форме по шампур-методу это понятие выражается парой вершин "Имя-Адрес" - своего рода контактом, если продолжать унификацию с ЕСКД, на желательность которой указывал Рэйлвей Каген. Как уже говорил - это не недостаток ШМ, если он действительно универсален.

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

Как итог - т.к. понятие никуда не девается, то и основания использовать его те же. Силуэтная часть ШМ просто вводит свои ограничения на употребление явного БП:

* не передавать управление назад (против хода исполнения, "шампура") иначе, как в силуэте на начало ветки (что, как известно, считается законным образованием цикла по одной или более ветке - но этот способ не обязательно даёт циклы, отвечающие требованиям структурности);

* не передавать управление в силуэте мимо входов веток (примерная ШМ-формулировка - "минуя петлю силуэта");

* не передавать управление с конца цепочки следования (ШМ-термин - "вертикали" - но он слишком общий) за пределы контура, внутри которого лежит начало этой цепочки (выход развилки, в точном смысле - побочный, ибо главные вертикали нужно считать непересаживаемыми).

Неструктурность веточных циклов возможна в силу того, что явные ограничения на пересечение их петель, как уже обсуждалось, в исходном ШМ не выписаны. Так что в этом смысле силуэт где-то эквивалентен Фортран-структурам управления.
Передача управления с заземлённых лиан также неструктурна - в частности, когда устраняет собой пересечения. Ибо одно из структурных ограничений для графовой формы записи - как раз отсутствие пересечений.

Главное же правило структурности для шампур-схем формулируется просто - это атомарность топологии схемы. Т.е. выводимость вложением (вводом атома). Причём структурный составной атом не должен содержать внутри пересечений (я понимаю, что это д.б. очевидно - но мы здесь о формальном определении). Это и будет "собственным (т.е. сформулированным для граф-шампур-формы записи структур управления) правилом ДРАКОНа, позволяющим сохранить структурность" ((С) П. Приклонский).

Любые другие правила структурность не сохраняют - см. теорему Бёма-Джакопини (достаточна композиция следований - линейных шампур-блоков - и циклов). И когда сочинитель оперирует с лианой так, что в примитиве (а равно и в примитивизированном силуэте) нарушается атомарность (возникает лианный, адресный макроблок) - он тем самым вводит явный БП. Который в текстовом виде потребует goto или заменителя - и это будет просто текстовым средством выражения того же понятия.
Действующие ШМ-правила сохраняют на самом деле планарность схемы как графа.

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

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

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

Уважаемый Владислав!

На это мое сообщение Вы дали обширный комментарий.

Ваш комментарий можно интерпретировать так, что Вы даете трактовку моему сообщению. Но это слишком вольная, я бы даже сказал ложная трактовка.

Ничего подобного я не имел в виду. Я имел в виду, что на указанных четырех страницах надо поправить несколько абзацев. И только.

Вы же пишете о фундаментальных изменениях. Но я вовсе не собираюсь производить такие изменения.

Таким образом, Вы (вольно или невольно) приписываете мне Ваши мысли. Не следует так поступать, потому что в результате возникает путаница.

Я не разделяю Ваши мысли. Вы считаете мое мнение ошибкой. И наоборот. Это значит, что между нами существуют разногласия.

Разумеется, Вы вправе разрабатывать и излагать любые идеи и теории, какие Вы считаете нужным. Но нужно понимать, что на белом свете существуют разногласия. Очень серьезные разногласия.

В этом нет ничего страшного. Это нормально. Разные люди часто имеют разные мнения.

Желаю Вам всяческих успехов.

Ну, тут Вы уточнили правильно - конечно, своих мыслей я никому не приписывал. Имелось в виду, что общий ход дискуссий в этой теме наводил на мысль - Илья, Рэйлвей Каген, Rifat так или иначе говорили о том же, что и я - и это как-то Вами будет учтено.

Уже после обширного комментария Вы в другой теме поместили сообщение, которое можно считать ответом на это. Отрицательным. И там же я спрашивал Вас, что по существу вытекает из этого отрицания? Наверное, повторять эти вопросы здесь не имеет смысла - чтобы не флудить.

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

И с Ильёй Вы не согласны: - что можно упорядочить дракон-схему, выводя "исчислением икон" только конструкции Дейкстры (при этом не забывая о формулировании охран, конечно)?

И с Rifatом: - что нужна эквивалентность и языкам без явных БП тоже?

И я уж не говорю о замечании Рэйлвей Каген, что принцип вложения также можно выразить в текстовой форме записи: viewtopic.php?p=52447#p52447.