А как обобщённый цикл в Вашем понимании соотносится с "гибридным"?..

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

То есть вот такого быть не должно:

ПРАВИЛО

В силуэте можно использовать:

— один веточный цикл;

— несколько независимых веточных циклов. Веточный цикл является независимым, если он не имеет общих участков с другими веточными циклами;

— вложенный веточный цикл, то есть веточный цикл, внутри которого находится другой веточный цикл;

— несколько вложенных веточных циклов.

ВЛОЖЕННЫЙ ВЕТОЧНЫЙ ЦИКЛ

Веточный цикл называется вложенным, если:

— икона «имя ветки» веточного цикла 1 находится левее иконы «имя ветки» веточного цикла 2;

— все иконы «адрес» веточного цикла 1 находятся правее икон «адрес» веточного цикла 2.

При описанных условиях веточный цикл 2 является вложенным в веточный цикл 1.

Можно сказать по-другому. Веточный цикл 1 является внешним, а веточный цикл 2 — внутренним.

В силуэте можно использовать:

... То есть "силуэт" однозначно развернётся в "примитив", без нарушения структурности.

Теорема. Примитив с любым числом пересечений можно преобразовать в эквивалентный ему силуэт (путем введения дополнительных переменных)

... зачем вообще нужно вводить понятие "веточный цикл" и особые иконки для него?

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

Я бы хотел Вам возразить не с точки зрения структрности, а с точки зрения проблемы пересечений. Мой тезис такой: Силуэт НЕ обязан превращаться в примитив (без пересечений).

Примитив с любым числом пересечений можно преобразовать в эквивалентный ему силуэт (путем введения дополнительных переменных)

А зачем вообще нужно вводить понятие "веточный цикл" и особые иконки для него.

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

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

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

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

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

Единственно, может быть, следует как то отметить ветки, на которые допустимы повторные входы.

Но вводить ограничения может быть всё-таки излишне.

Достижимость выхода по идее должна проверять среда разработки, я имею структурно достижимую - должна быть цепочка переходов по силуэту от входа к выходу.

Но если есть хоть один "веточный цикл" - то гарантий уже дать нельзя , это уже вопрос корректности алгоритма, который должен гарантировать "выходимость" из "веточных циклов".

Но ограничения на наличие ВЦ всё же думаю не нужны.

Может быть нужны предупреждения среды разработки ?

Уважаемый Эдуард!

Вы задали вопрос про цикл в примитиве здесь.
http://forum.oberoncore.ru/viewtopic.php?p=70268#p70268



Мой ответ таков.

1. Язык ДРАКОН определен через графический синтаксис. Текстовый синтаксис не определен и может быть любым.

2. Как определен графический синтаксис? Он определен ДВОЯКО.
Во-первых, он определен через формальное описание (37 тезисов, изложенных в главе «Графический синтаксис языка ДРАКОН»). В последней книге это Глава 33, стр. 416—424.
Во-вторых, что очень важно, графический синтаксис определен через мое описание дракон-редактора. В последней книге это «Глава 32. Конструктор алгоритмов (помощник человека)», стр. 395—415.
http://drakon.su/_media/biblioteka/chas ... isanie.pdf

3. Оба описания (формальное и через действия редактора) должны быть тождественны. Если они не совпадают, значит, это ошибка. Мне о таких ошибках неизвестно. Я исхожу из того, что ошибок нет и оба описания тождественны.

4. Отсюда вытекает, что правильно построенный дракон-редактор является инструментом не только для конструирования правильных дракон-схем, но и инструментом ДЛЯ ПРОВЕРКИ готовой дракон-схемы, относительно которой есть сомнения, что она правильная. Это именно Ваш случай, Эдуард.

5. Отсюда следует порядок действий. Глядя на Вашу схему, следует провести мысленный эксперимент (а лучше эксперимент с помощью карандаша и бумаги). Попробуйте преобразовать заготовку-примитив в Вашу схему, с помощью конечного числа шагов идеального дракон-редактора, соответствующего моему описанию.
Если получится, значит, Ваша схема правильная. И наоборот.

6. Описанная проверка (через действия редактора) не заменяет проверку на соответствие формальному описанию, а дополняет ее. Хотя по сути эти проверки тождественны. Преимущество проверки через действия редактора состоит в том, что она более наглядна. В том смысле, что «метод через построение» позволяет пощупать построение руками (на каждом шаге построения).

ВЫВОДЫ

В1. Графический синтаксис языка ДРАКОН определен двумя разными методами: декларативным и процедурным, каждый из которых является математически строгим.

В2. Декларативный метод представляет собой формальное описание графического синтаксиса с помощью 37 тезисов.

В3. Процедурный метод представляет собой формальное преобразование заготовки-примитив в формальную дракон-схему примитив с помощью идеального дракон-редактора, поведение которого в случае необходимости можно смоделировать вручную (с помощью карандаша и бумаги).

В4. Все сказанное выше про примитив относится и к силуэту.

==============================================

Повторю главную мысль. Графический синтаксис языка ДРАКОН описан не одним, а двумя разными способами. Это улучшает надежность описания и упрощает возможность его проверки.
http://drakon.su/_media/biblioteka/chas ... isanie.pdf