Степан Митькин писал(а):
Постановляю:
Считать иконы Ввод, Вывод, Пауза и Параллельный процесс переключающими контекст.
...
Почему?
Потому что так удобно программировать. Компьютер так устроен.
Это не соответствует ГОСТу? Очень жаль.
Зато это соотносится с тем, как работают "современные" операционные системы.
Степан, проблематика не в соответствии ГОСТу как таковом, а в Дракон-философии, что ли. Из-за естественного стремления к эргономике в Дракон-е возникает эффект "мульти-метафор" и "диалектов", так что ли назвать происходящие явления, не знаю как именно.
К примеру, в попытке обобщения семантики в контексте "реального времени и диспетчера" Вы для "вывода" определяете лишь один вариант семантики. Но в общем случае с алгоритмической точки зрения выделяются, как минимум, следующие ситуации (которые могут быть в рамках даже одного и того же проекта или программы, не то чтобы в разных предметных областях):
1) напр., при операции с файлом исполнительный поток должен быть заблокирован (хотя бы виртуально) в том смысле, что не должно быть переключения контекста на смежные (заинтересованные) процессы -- данный алгоритм не сигнализирует о завершении предметного такта работы, лишь выполняет свою "рутину";
2) алгоритм сигнализирует о завершении прикладного шага в работе, при этом:
2.1) поток не должен быть заблокирован (по возможности, во всяком случае, алгоритм не требует блокировки);
2.2) поток блокируется по мотивам организации кооперативной многозадачности (пока не завершаться смежные и прочие необходимые процессы);
3) отправка сигнала синхронизации типа "освобождения мьютекса" и т.п. -- поток не блокируется и алгоритм формирует управляющий сигнал в контексте организации работы процессов (в отличие от случая 2.1, где предполагается передача предметных данных как результатов своего труда, может быть в какие-то входные очереди/буферы иных процессов).
Уточнения выше не являются вспомогательными в смысле как уточнение параметров/адресатов (мол "отправляем документ такой-то в отдел такой-то"), а определяющими в контексте организации управления действиями -- ключевого аспекта самих схем как таковых. И, вроде как, намечается новый "стандарт" (если Ваши усилия так воспринимать), но его не достаточно. Вводить новые иконы -- вариации "вывода" с закорючками -- язык запрещает, ибо уже тогда появляется новый язык как таковой (да и эргономика при "мозаиках" под вопросом). Но "диалекты" возникают всё равно, в ином виде. К примеру, "стандарт" предопределяет использование икон реального времени так -- "взвод" таймера (в ноль, напр.) и возможно множество сопряжённых точек ожидания/синхронизации в зависимости от отсчитанного времени:
https://forum.drakon.su/viewtopic.php?f=78&t=6263#p101816Однако, от TAU мы наблюдаем уже "диалект" этих же икон -- взвод УВИ на конкретное время и одну связанную точку синхронизации, где в "синхронизаторе" время уже не указывается:
https://forum.drakon.su/viewtopic.php?f=176&t=6221#p101429В последнем случае возникает потребность в своей "таблице семантики" для элементов языка, отличной от стандартной.
В "стандарте" в рамках универсального пути можно было бы семантику иконы "пауза" сделать некой предельно общей, по аналогии с блок-схемами, где эта же икона есть "ручная операция" -- "символ отображает любой процесс, выполняемый человеком" (но в программах символ не используется). В Дракон-е можно было бы определить "икону-трапецию" как "любой процесс, выполняемый диспетчером", с примерами методик. Однако, в Дракон-е для "не программной" предметки эти же "паузы" выражают "длительность действий" -- нет никаких диспетчеров/переключений контекста/ожиданий, и, главное то, совсем уже иная "маршрутная" семантика (и непонятно что делать, если в одной и той же предметке рядом с программой необходимо показать и "протокол о намерениях" с те ми же ограничениями/оценками периодов).
А выше в теме был отмечен "диалект" иного плана, вроде как, под надзором "Дракон-комитета" -- настройка конечной семантики исполнения программы в рамках переключения контекста -- действие-шаг, ветка-шаг, схема-шаг и т.п.
Т.е. кроме таблицы семантики икон необходимы и какие-то таблицы семантики интерпретации маршрутных линий (или в целом правил интерпретации понятия передачи управления).
Если пользователи наблюдают "произвол" и поощрение "не делать лишнюю работу", то они в рамках нового "стандарта" вполне в праве потребовать "удобного" цикла вида "для" с возможностью "ожидания", т.к. у них прямо в спецификации может быть написано: "для каждого такого-то события выполнять ...", и без цикла "для" происходит искажение исходной эргономики постановки задачи (если такой цикл организовывать иными конструкциями).
А если "одобрямс" от "Дракон-комитета" поддерживает: "ожидающие циклы -- с позиции читателя это правильно, нет лишней работы, так эргономично -- и это главное", и "стандарт" будет подкорректирован, то, к примеру, и "ожидающих вопросов" не избежать в итоге. Напр., возникнет новое направление -- "интеллектуальное бизнес-управление", где какие-то "проталкиватели" курсов/продукта постановят: после команды "Ок,
[s]Google[/s] Дракон!" схема переходит в особый режим, где "решения" в иконах "вопрос" принимает не человек, а Дракон-диспетчер с "искусственным интеллектом", на которого в иконе неявно осуществляется переключение контекста исполнения -- мол так подчёркивается "фишка" интеллектуального управления, ведь так эргономично -- раскрывается сама суть технологии, и Дракон на передовой искусственного интеллекта!
Я конечно же, приукрашиваю, но основное -- возникнут или уже есть какие-то "диалекты", где смена семантики икон/элементов языка может происходить динамически внутри схемы (и те же иконы-"вопросы" -- не исключение).
Итого, впечатление, что философия Дракон-а -- прежде всего визуальная эргономика. И принцип организации Дракон-семейства гибридных языков -- корректировка семантики элементов языка -- ситуативное формирование предметных таблиц семантики, что наблюдается по сторонам. И ведь, как минимум, в новом предлагаемом "стандарте" для иконы "вставка" формулировка "зависит от ДРАКОН-схемы, на которую указывает" предполагает прикладное уточнение поведения в контексте управления.
Возможно, такой путь вынужденный в некотором смысле, и он даже нужен как альтернатива блок-схемам с целью решения проблем визуальной эргономики.
И, может быть, как раз в рамках иконы "вставка" есть смысл и ограничить свободу в формировании вариаций управления, те же иконы "ввод/вывод" всё равно не покрывают все варианты без уточнения (параллельные процессы и паузы/синхронизаторы имеют более предметную нагрузку в своей основе). Но с другой стороны, без ввода/вывода пострадает эргономика в тех местах, где напрашивается применение этих икон. Тогда, вроде как, напрашивается введение необходимости уточнения "зависит от ..." и для "ввода/вывода". И циклы "для" тогда уж требуют "свободы", если в их нагрузке использовать те же процессы с переключениями/ожиданиями как и в "ставках".
В общем, возникают предметные таблицы семантики управления, что есть существенная особенность языка.