DRAKON.SU

Что-то подобное, выше, я уже показывал.
На мой взгляд, веточный цикл проигрывает в выразительности циклу FOR (конечно, для определённых случаев).

А для вложенных циклов — проигрывает сильно.

Да, выразительнее конечно...
А как в таком случае будет происходить редактирование схемы, в каких элементарных операциях это может выразиться? Вставкой заготовки "многоветочный цикл FOR"?

Например, пересадкой иконы "Конец цикла FOR" на главный маршрут соответствующей ветки. Так сказать, метод Мичурина : )

Так, теперь и пересадка икон уже будет?

Может быть Владимир Паронджанов подскажет как делать правильно?

Уважаемый Владислав Жаринов (Драконограф)!

Я опираюсь на следующие соображения.

1. Работники нашего Пилюгинского центра (непрограммисты, то есть
инженеры и комплексники) используют цикл ДЛЯ, в том числе занимающий
несколько веток.

Я не слышал от них никаких жалоб или замечаний по этому поводу.
Они все прекрасно понимают. Это для меня РЕШАЮЩИЙ аргумент.

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

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

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

2. Я не всегда соглашаюсь с мнением этих людей (инженеров - разработчиков алгоритмов). Но для возражений у меня должна быть железная аргументация.

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

4. ГОСТ -- для меня не святыня. У меня всегда есть возможность
написать и утвердить руководящий документ, который будет иметь силу
ГОСТа. И нормоконтроль будет проверять документацию на соответствие
установленных мной (по согласованию со всеми заинтересованными
сторонами) правил.

5. Но на ровном месте я стараюсь (если это разумно) от ГОСТа
не отступать. Цикл ДЛЯ -- как раз такой пример.

6. В этой теме обсуждаются вопросы, которые частично выходят
за рамки моей уверенности и моих знаний.

7. Я бы сказал, что в этой теме ведется научно-исследовательская
работа. Высказан ряд интересных предложений. Все это трбует обдумыва-
ния.

8. Эдуард Ильченко задал вопрос:

На этот вопрос я должен честно признаться: не знаю.

Как же быть? Мне кажется, надо искать решение сообща, в рамках коллективной
творческой дискуссии.

Спасибо, понятно.

В и.с. Drakon блок "Цикл ДЛЯ" является неделимой и локальной конструкцией. Этим обеспечивается логичность выполнения действий: "Удаление иконы", "Удаление шампур-блока", "Удаление ветки", тоже с копированием, вставкой и заменой.

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

Итак, в разветвлённо-силуэтных диоформах задание структуры маршрутов принципиально не м.б. сведено только к графчасти (для линейных силуэтов это возможно, если следовать правилу порядка - напр. "чем правее, тем позже"). Нужен текст - и чем меньше такого текста будет, тем лучше для чтения.
Далее, техноязык в определении, допускающем многоветочный ДЛЯ в силуэте, позволяет выражать на нём циклы с параметром и так, и этак - и определение каждого случая становится уже задачей технологии. Имеется в виду, что можно визуализировать как через ДЛЯ, так и через многоветочный цикл - где уже будет явным и условие цикла, и адреса переходов. Но и здесь мы должны руководстваться удобством сочинения и чтения. Поэтому не следует и пытаться обозначать веточные циклы чисто графически - нужно явно различать их как однородные структурные образования, назначая им индексы (что и предложено в /Паронджанов, 2001, Рис.105...107/) - и отразить это в алфавите и правилах языка. Это та же самая минимально необходимая "графитизация" шампур-метода, что и идентификация веток.
Из сказанного также вытекает, что ограничения или запрет многоветочности цикла ДЛЯ нужно будет заложить в определение языка - чтобы не было противоречия с запретом передачи управления в силуэте, минуя его петлю.
А как работать в рамках, установленных определением языка - это уже описывается определением технологии его применения. Здесь м.б. и "проектные образцы", и примеры их использования для конкретных целей.

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

Свой взгляд на то, как поступать при визуализации сложных циклов с параметрами, я отразил в примерах - о преобразовании в обычные циклы в дракон-программе работы ДСК из этого примера и о приведении к ЦД в этом примере. Правильно это или нет в каких-то теоретических аспектах - можно обсуждать. Эргономически тем или иным людям может быть привычнее шапка-подвал цикла ДЛЯ - но это легко уравнивается введением формальных комментариев в тексты заменяющих их вершин (что используется в обоих примерах). А вот структура переходов без сокрытия условий циклов становится явной и поведение алгоритма легче прослеживается - или нет?