PSV100 писал(а):
Но автоматные спецификации есть универсальный способ алгоритмического представления для разных требований "выразительности". Имея их, ими можно вертеть с разных сторон, выражая задание трасс исполнения (не обязательно всей системы, это может быть некий протокол о намерениях в разрезе определенного аспекта) для уточнения или объяснения, проверок и верификации, для генераций тестов или/и имитационных моделей, для спецификаций будущих реализаций (может быть распределенных, на разных платформах) и пр. И не только в линеаризованной форме (в стиле кода atFloor на Kotlin выше),
И? Что это значит?
Значит, что нужно использовать формализм в духе atFloor? Нет.
Значит, что в бытовом программировании нужно использовать формализм в духе atFloor? Вовсе нет.
Я аналогичный пример приведу: язык ассемблера это универсальный способ алгоритмического представления разных программ для процессора Intel Core. Имея программу на этом языке можно вертеть её с разных сторон и так далее.
Значит ли это, что нужно всем пропагандировать ассемблер? Разумеется, нет.
Так и с atFloor. По-моему, это маргинальный подход. На нём можно писать только в FSM-callback стиле, и простую программу "светофора" написать невозможно. Нужно выдумывать состояния и тому подобное.
PSV100 писал(а):
И понятно удобство, как бы, последовательного (с паузами/переключениями) постепенного перемещения по алгоритмической трассе (с возвратами, если нужно), на которое, по-видимому, вы постоянно акцентируете.
Именно. Я не говорю, что нужно 100% программ именно в таком виде писать. Но я утверждаю, что способность выражать программы в таком стиле очень важна для "бытового" программирования.
Не в виде переходов между состояниями, а именно в императивном подходе "сделай раз, сделай два, сделай три".
В atFloor такой стиль невозможен.
В редакторе Тышова есть реверанс в подобную сторону: то ли у схемы, то ли у листа можно указывать "режим трансляции", который влияет на результирующий код (1 действие==1 состояние FSM, 1 ветка == 1 состояние FSM и тому подобное)
В Kotlin'е аналогично: добавили suspend модификатор -- функция компилируется в FSM. Не добавили -- компилируется в обычный код.
PSV100 писал(а):
Вы для примера использовали функцию yield в совокупности с типовыми управляющими операторами. В иных случаях встретится код на каком-нибудь аля "Reactive Streams API", в итоге вроде и язык один и тот же вместе с тем же механизмом suspend functions, но возникает существенный диалект, с которым нужно и существенно разбираться, чтобы понять модель вычислений. Т.е. выразительность как таковой самой концепции блокируемых/приостанавливаемых операций где-то сбоку, прежде всего, важно семантическое содержательное, предметное наполнение.
Не соглашусь. Выразительность концепции suspend functions позволяет создать функцию yield, которая приводит к "приостановке выполнения", и которая при этом правильно работает с обычными языковыми конструкциями if/for/try.
Да, в одной задаче может удобнее быть остановка выполнения командой yield, в другой задаче может оказаться удобнее a-la Reactive, в третьей задаче может удобно создать функцию, которая генерирует значения (ну, которая как бы бесконечно выполняет return, но после каждого возвращённого значения она приостанавливается).
Да, может потребоваться "въезжать" в предметное наполнение, но тратить время на понимание стиля нового для вас кода придётся в любом случае.
Та же самая "гиперфункция" atFloor. Она встречается только в одном конкретном проекте. Хоть так, хоть сяк придётся тратить время на понимание происходящего. Если в проекте сделали самопальную функцию yield, то, да, первый раз она может удивить. Но это не значит, что она ставит читателя в тупик на неделю.
Само же написание подобных функций как раз и становится возможным благодаря suspend functions.
Иными словами, механизм suspend functions позволяет строить предметно-ориентированные надстройки, которые потом легко использовать на бытовом уровне даже тем, кто не понимает за счёт какой магии оно работает.
С atFloor так невозможно.
В Дракон-схемах вопрос "семантики результирующего FSM" тоже не проработан.
=====
На тему configurable semantics in FSM есть исследование и рабочая интеграция с С кодом:
https://github.com/z9luo/BSML-mbeddrВполне может быть, что семантика состояний должна настраиваться по удобству конкретного алгоритма.
К слову, в той статье один из режимов был
syntactic big-step maximality. Т.е. когда "стабильные" состояния FSM размечаются руками программиста, и система выполняет переходы до тех пор, пока не дойдёт до стабильного.
Вполне может быть, что нужно не искать идеальный вариант компиляции Дракон-схемы в FSM, а делать несколько настраиваемых вариантов.