Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, CodingUnit, Вы писали:
CU>>нет все верно, Extern — это событие если студент экстерном хочет сдать все сразу, и переходит ко 2й, смысл здесь лишь в том как работает fork псевдосостояние, оно дает вход в любые состояния в разных регионах параллельного состояния, это его синтаксис, то есть переход в несколько.
FDS>Тогда надо его указывать на диаграмме, чтобы было стопроцентрое соответствие: иначе пример бесполезен.
на диаграмме не стал, потому что пример взят из справочника, как картинка, перерисовывать я не стал, а добавить переход хотел
FDS>>>Непонятно, почему есть FDS>>>initial => FinalTest;
FDS>Дело в том, что переход осуществляется только для FinalTest, а лабораторные работы не инициализируются. Вопрос в этом. А синтаксис, честно говоря, я бы вообще другой сделал бы Так что не в этом дело.
там работает auto_initial, если указан явный то auto_initial пропускает его и оставляет какой есть
FDS>>>но нет таких же в других параллельных состояниях
CU>>нет потому что здесь я явно указал куда хочу сделать переход, а в остальных случаях они определяются автоматически через флаг в начале описания автомата CU>>
CU>>flags : auto_initial;
FDS>Опять же, с точки зрения обучения нужно или и там и там использовать флаги, или и там, и там ставить всё вручную (или комментировать не обязательный код, если хочешь показать, что он могу бы быть, но не нужен)
я просто показал разные варианты применения
FDS>Про запомненное состояние автомата я неверно спросил. FDS>Верно как-то так: можно ли в автомат переходить не в состояние, а посылать ему сигнал? Т.е. переходим в сам автомат, находящийся в некотором состоянии (последнее, из которого он вышел вовне) и у него сразу же какое-то событие случается? (применений не знаю, просто интересно можно или нет)
это возможно через действия, смотри предыдущие сообщения, при входе в состояние оно может запускать действие, которое посылает в автомат событие, хотя сейчас события синхронны и если запустить событие когда он еще осуществляет переход, то он сначала будет реагировать на это событие, а потом завершит переход в состояние, то есть получится не совсем что нужно, для этого наверное надо делать очередь асинхронных событий, это я тоже планировал и посылать их так
FDS>>>Можно ли определить метку, двигающуюся по автомату, CU>>для чего и что это за метка такая, как она должна выглядеть? автомат и так имеет текущее состояние это и есть метка
FDS>Да нет. Представь себе, что это что-то типа сети петри: если метка есть, переход в одно состоянии при некотором сигнале, если метки нет — то и переход в другое состояние или перехода нет (ну, это я просто спрашиваю, грубо говоря, как раз на счёт того, только ли это конечный автомат).
я в сетях петри не разбираюсь, в семантике UML есть псевдосостояния, которые реализуют похожее поведение, есть synch псевдосостояние, которое ожидает некое количество переходов в себя и только после этого осуществляет переход, есть choice и junction, они осуществляют динамический и статический выбор пути перехода в зависимости от условий, только то что есть в семантике автомата UML я собираюсь реализовывать
CU>>У тебя есть мысли как это сделать лучше? глобальные имена используются и в языках на которых мы пишем, можно конечно использовать и прямую спецификацию имени, чтобы уточнить путь, это поддерживается например можно написать так A.B это будет обозначение подсостояния B в A
FDS>Ну, лично мое мнение, не претендую на верность совершенно, что лучше выглядело бы так
FDS>state TakingClass FDS>{ FDS> Extern => Incomplete.Lab2 Incomplete.TermProject Incomplete.FinalTest; FDS> => Incomplete; // переход из ничего — инициализация
синтаксис с Incomplete разрастается и выглядит больно наворочено на глаз, кто пишет код из диаграммы разве не поймет какое состояние он хочет указать? без прямой спецификации
FDS> state Incomplete FDS> { FDS> _ =>> Passed; // обозначаем для невнимательных, что здесь переход идёт вовне
разный синтаксис для типов переходов возможен, я думал делать local и external переходы с разным синтаксисом, думаю можно сделать синтаксис чтобы явно указывать куда переход во вне или внутри состояния, тогда это будет еще дополнительная проверка на правильность если состояние окажется не тем куда задумывался переход
FDS> => Lab1 TermProject FinalTest;
здесь не понял откуда предполагается fork переход, он уже есть во вне из того состояния внутрь параллельного, это дупликация
FDS> [----------] // лишняя граница, т.к. "_" работает синхронно
FDS> state Lab1 FDS> { FDS> lab_done => Lab2; FDS> }
FDS> extern state Lab2 FDS> { FDS> lab_done => ; FDS> }
по моему не очевидно, цель перехода должна быть указана явно, иначе это может быть ошибкой, переход может быть не только в конечные состояния, но
и в другие типы псевдосостояний, например H (для history) и остальные, и => без конца может дать проблему в парсере
FDS> [----------]
FDS> state TermProject FDS> { FDS> project_done => ; FDS> }
FDS> [----------] FDS> state FinalTest FDS> { FDS> pass => ; FDS> fail =>> Failed; // переход во вне FDS> } FDS> }
FDS> state Passed FDS> { FDS> }
FDS> state Failed FDS> { FDS> } FDS>}
FDS>А если бы при этом ещё и был indentation-синтаксис — было бы вообще прекрасно. Но это чисто моё мнение, мне автоматы очень редко надобятся.
можно подумать про indentation
Здравствуйте, CodingUnit, Вы писали:
FDS>>Опять же, с точки зрения обучения нужно или и там и там использовать флаги, или и там, и там ставить всё вручную (или комментировать не обязательный код, если хочешь показать, что он могу бы быть, но не нужен) CU>я просто показал разные варианты применения
Ну вот это плохо, что ты сделал — запутывает. Надо тогда комментировать этот код, что он не обязателен
CU>я в сетях петри не разбираюсь, в семантике UML есть псевдосостояния, которые реализуют похожее поведение, есть synch псевдосостояние, которое ожидает некое количество переходов в себя и только после этого осуществляет переход, есть choice и junction, они осуществляют динамический и статический выбор пути перехода в зависимости от условий, только то что есть в семантике автомата UML я собираюсь реализовывать
Нет, через псевдосостояния я так понимаю это не реализовать.
Грубо говоря, не помешала бы какая-то возможность прикрепить к потоку на графе состояний объект — метку. Я не знаю, сложно ли это сделать, если легко, то лучше сделать, даже если выходит за UML, если сложно, тогда, конечно, увы.
Привожу пример:
Есть автомат из трёх состояний
0 — начальное
если нет метки — перейти по сигналу в 1
если есть метка и она попадает под "условие1", то перейти в 2
иначе — перейти в 3
1
Поставить метку с "условие1"
Перейти в 0 при сигнале
2
Если нет метки — фатальная ошибка
Изменить метку на "условие2"
Перейти в 0 при сигнале
Т.е., грубо говоря, к потоку прикрепляется объект или несколько, которые затем модифицируется (в идеале тут ещё нужны стандартные условия и функции модификации, чтобы можно было просто описывать введённые пользователем понятия, например, количества меток и условия перехода по количеству меток без функций). При этом, идеально, если возможно будет все состояния сделать параллельными. Тогда это уже не просто автомат, но, по-сути, заготовка для сети петри, а то и заодно и сама размеченная сеть петри.
FDS>>state TakingClass FDS>>{ FDS>> Extern => Incomplete.Lab2 Incomplete.TermProject Incomplete.FinalTest; FDS>> => Incomplete; // переход из ничего — инициализация
CU>синтаксис с Incomplete разрастается и выглядит больно наворочено на глаз, кто пишет код из диаграммы разве не поймет какое состояние он хочет указать? без прямой спецификации
Диаграммы может и не быть, или она может быть на такая, как программируется автомат. Ты сам ввёл лишний переход, которого не было на диаграмме, что уж говорить о реальном проекте.
С моей точки зрения — лучше навернуть или указать что-то такое
Extern => Incomplete(Lab2 TermProject FinalTest);
Просто если автоматами описывать логику работы, то очень быстро запутаешься, что куда переходит, особенно если не ты этот автомат начинал делать.
FDS>> state Incomplete FDS>> { FDS>> _ =>> Passed; // обозначаем для невнимательных, что здесь переход идёт вовне CU>разный синтаксис для типов переходов возможен, я думал делать local и external переходы с разным синтаксисом, думаю можно сделать синтаксис чтобы явно указывать куда переход во вне или внутри состояния, тогда это будет еще дополнительная проверка на правильность если состояние окажется не тем куда задумывался переход
Ну значит это точно надо, раз мы оба подумали
FDS>> => Lab1 TermProject FinalTest; CU>здесь не понял откуда предполагается fork переход, он уже есть во вне из того состояния внутрь параллельного, это дупликация
Это явное описание инициализации, т.к. флаг автоматической инициализации я убрал. Т.е. когда мы запишем инициализацию => Incomplete; то эта строка будет указывать как бы состояния по-умолчанию.
CU>по моему не очевидно, цель перехода должна быть указана явно, иначе это может быть ошибкой, переход может быть не только в конечные состояния, но CU>и в другие типы псевдосостояний, например H (для history) и остальные, и => без конца может дать проблему в парсере
Ну, просто это более долго писать Про проблему в парсере я понимаю, хотя в целом такой переход можно поставить первой веткой выбора, чтобы проблем не было (конечно, если в других ветках не ожидается ";" внутри описания).
FDS>>А если бы при этом ещё и был indentation-синтаксис — было бы вообще прекрасно. Но это чисто моё мнение, мне автоматы очень редко надобятся. CU>можно подумать про indentation
Было бы очень неплохо. Хотя не знаю, насколько это PEG осилит
Просто тогда это было бы несколько более приятно читать, как мне кажется. Грубо говоря, то, что я хочу, выглядело бы так
state TakingClass
$0
Incomplete
Extern
Incomplete
Lab2
TermProject
FinalTest
Incomplete
_
Passed:> // :> - описываем, что это внешний идентификатор
$0
Lab1
TermProject
FinalTest
[---]
Lab1:> // :> это состояние связано с начальным состоянием автомата
lab_done здесь можно через пробел и другие состояния указывать
Lab2
Lab2:>> // :>> описываем видимость с двойным выходом наружу - на внешний автомат
lab_done
$0
[---]
TermProject:>
project_done
$0
[---]
FinalTest
pass
$0
fail
Failed:>
Passed
Failed
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, CodingUnit, Вы писали:
FDS>Ну вот это плохо, что ты сделал — запутывает. Надо тогда комментировать этот код, что он не обязателен
ну постараюсь исправиться, сам пост вряд ли уже можно отредактировать
CU>>я в сетях петри не разбираюсь, в семантике UML есть псевдосостояния, которые реализуют похожее поведение, есть synch псевдосостояние, которое ожидает некое количество переходов в себя и только после этого осуществляет переход, есть choice и junction, они осуществляют динамический и статический выбор пути перехода в зависимости от условий, только то что есть в семантике автомата UML я собираюсь реализовывать
FDS>Нет, через псевдосостояния я так понимаю это не реализовать. FDS>Грубо говоря, не помешала бы какая-то возможность прикрепить к потоку на графе состояний объект — метку. Я не знаю, сложно ли это сделать, если легко, то лучше сделать, даже если выходит за UML, если сложно, тогда, конечно, увы.
FDS>Привожу пример:
FDS>Есть автомат из трёх состояний FDS>0 — начальное FDS> если нет метки — перейти по сигналу в 1 FDS> если есть метка и она попадает под "условие1", то перейти в 2 FDS> иначе — перейти в 3 FDS>1 FDS> Поставить метку с "условие1" FDS> Перейти в 0 при сигнале FDS>2 FDS> Если нет метки — фатальная ошибка FDS> Изменить метку на "условие2" FDS> Перейти в 0 при сигнале
тут мне кажется подойдет choice / junction псевдосостояния, они могут иметь прикрепленные сторожевые условия, переход осуществляется туда где условие истинно, к этому условию можно прикрепить что угодно функцию, делегат, главное чтобы отрезок возвращал bool, в этой функции можно делать что угодно и расчитывать пути как вздумается, если эта вещь будет переиспользуемая то можно подумать о введении синтаксиса. Пока это похоже на динамический доступ к переходам, его можно имитировать как я сказал
FDS>Т.е., грубо говоря, к потоку прикрепляется объект или несколько, которые затем модифицируется (в идеале тут ещё нужны стандартные условия и функции модификации, чтобы можно было просто описывать введённые пользователем понятия, например, количества меток и условия перехода по количеству меток без функций). При этом, идеально, если возможно будет все состояния сделать параллельными. Тогда это уже не просто автомат, но, по-сути, заготовка для сети петри, а то и заодно и сама размеченная сеть петри.
в пределах семантики UML я думаю можно сделать довольно много из того что ты сказал, автомат представляет собой класс, поэтому можно переопределять сторожевые условия и события, junction и choice я собирался добавлять, которые также можно будет переопределять в классе
CU>>синтаксис с Incomplete разрастается и выглядит больно наворочено на глаз, кто пишет код из диаграммы разве не поймет какое состояние он хочет указать? без прямой спецификации
FDS>Диаграммы может и не быть, или она может быть на такая, как программируется автомат. Ты сам ввёл лишний переход, которого не было на диаграмме, что уж говорить о реальном проекте. FDS>С моей точки зрения — лучше навернуть или указать что-то такое FDS>Extern => Incomplete(Lab2 TermProject FinalTest);
так выглядит лучше, надо подумать про такой синтаксис
FDS>Просто если автоматами описывать логику работы, то очень быстро запутаешься, что куда переходит, особенно если не ты этот автомат начинал делать.
FDS>Ну значит это точно надо, раз мы оба подумали
я пометил себе добавить такую возможность
FDS>>> => Lab1 TermProject FinalTest; CU>>здесь не понял откуда предполагается fork переход, он уже есть во вне из того состояния внутрь параллельного, это дупликация
у меня в каждом регионе независимое начальное состояние, которое должно указываться там же, эта запись конфликтует с синтаксисом fork перехода
CU>>по моему не очевидно, цель перехода должна быть указана явно, иначе это может быть ошибкой, переход может быть не только в конечные состояния, но CU>>и в другие типы псевдосостояний, например H (для history) и остальные, и => без конца может дать проблему в парсере
FDS>Ну, просто это более долго писать Про проблему в парсере я понимаю, хотя в целом такой переход можно поставить первой веткой выбора, чтобы проблем не было (конечно, если в других ветках не ожидается ";" внутри описания).
на два символа дольше, но не очевидно куда хотел быть переход, кстати конечные состояния не так часто используются чтобы делать для них такой экстравагантный синтаксис, для final можно сделать синтаксис в один символ, только надо подумать какой выбрать
FDS>>>А если бы при этом ещё и был indentation-синтаксис — было бы вообще прекрасно. Но это чисто моё мнение, мне автоматы очень редко надобятся. CU>>можно подумать про indentation
FDS>Было бы очень неплохо. Хотя не знаю, насколько это PEG осилит
FDS>Просто тогда это было бы несколько более приятно читать, как мне кажется. Грубо говоря, то, что я хочу, выглядело бы так
FDS>
FDS>state TakingClass
FDS> $0
FDS> Incomplete
FDS> Extern
FDS> Incomplete
FDS> Lab2
FDS> TermProject
FDS> FinalTest
FDS> Incomplete
FDS> _
FDS> Passed:> // :> - описываем, что это внешний идентификатор
FDS> $0
FDS> Lab1
FDS> TermProject
FDS> FinalTest
FDS> [---]
FDS> Lab1:> // :> это состояние связано с начальным состоянием автомата
FDS> lab_done здесь можно через пробел и другие состояния указывать
FDS> Lab2
FDS> Lab2:>> // :>> описываем видимость с двойным выходом наружу - на внешний автомат
FDS> lab_done
FDS> $0
FDS> [---]
FDS> TermProject:>
FDS> project_done
FDS> $0
FDS> [---]
FDS> FinalTest
FDS> pass
FDS> $0
FDS> fail
FDS> Failed:>
FDS> Passed
FDS> Failed
FDS>
FDS>Но это, конечно, моё видение.
конечно приятно читать, я пометил сделать такой синтаксис, в парсере по идее не должно быть проблем, надо будет просто потом обрабатывать дерево после парсинга и парсить по другим правилам
Здравствуйте, CodingUnit, Вы писали:
CU>тут мне кажется подойдет choice / junction псевдосостояния, они могут иметь прикрепленные сторожевые условия, переход осуществляется туда где условие истинно, к этому условию можно прикрепить что угодно функцию, делегат, главное чтобы отрезок возвращал bool, в этой функции можно делать что угодно и расчитывать пути как вздумается, если эта вещь будет переиспользуемая то можно подумать о введении синтаксиса. Пока это похоже на динамический доступ к переходам, его можно имитировать как я сказал
Если все состояния сделать параллельными, то не пройдёт, т.к. мы будем иметь автомат с набором состояний, ограниченным не одним из возможных, а всеми из возможных и метка должна будет двигаться по сети, а не быть статической.
Кроме этого, даже если брать один автомат, тогда нужно где-то хранить данные, к нему привязанные. В т.ч. хранить данные для вложенных автоматов.
Вообще, я так подумал, это довольно сложно сделать. По-сути надо тогда синтаксис делать расширяемым, грубо говоря, с возможностью написать нечто типа некоторое_слово[параметры] и затем передать это через рефлексию в функцию с именем некоторое_слово со списком параметров, которые она сама будет парсить. И при этом это уже тогда получается автомат сам, наверное, надо менять, чтобы количество параллельных состояний было ограниченным лишь количеством объявленных состояний.
CU>у меня в каждом регионе независимое начальное состояние, которое должно указываться там же, эта запись конфликтует с синтаксисом fork перехода
Странно, конечное состояние, общее для параллельных регионов, есть, а начального нет... по идее, должно быть такое состояние, а эта запись тогда есть fork-переход из него. Ну раз нет, значит не надо, но вообще, гораздо проще его было бы задать как я написал, чем задавать отдельно вручную для каждого региона (если отключить флаг автоматического определения начального состояния).
CU>на два символа дольше, но не очевидно куда хотел быть переход, кстати конечные состояния не так часто используются чтобы делать для них такой экстравагантный синтаксис, для final можно сделать синтаксис в один символ, только надо подумать какой выбрать
Я так понял, что final — это ещё одна форма записи конечного состояния. Это не так?
Согласен, экономия в пару символов ничего особенного не даёт.
CU>конечно приятно читать, я пометил сделать такой синтаксис, в парсере по идее не должно быть проблем, надо будет просто потом обрабатывать дерево после парсинга и парсить по другим правилам
Ну да, просто, честно говоря, я не очень понимаю, как такое в PEG правильно сделать — чтоб он табуляции считал.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, CodingUnit, Вы писали:
CU>>тут мне кажется подойдет choice / junction псевдосостояния, они могут иметь прикрепленные сторожевые условия, переход осуществляется туда где условие истинно, к этому условию можно прикрепить что угодно функцию, делегат, главное чтобы отрезок возвращал bool, в этой функции можно делать что угодно и расчитывать пути как вздумается, если эта вещь будет переиспользуемая то можно подумать о введении синтаксиса. Пока это похоже на динамический доступ к переходам, его можно имитировать как я сказал
FDS>Если все состояния сделать параллельными, то не пройдёт, т.к. мы будем иметь автомат с набором состояний, ограниченным не одним из возможных, а всеми из возможных и метка должна будет двигаться по сети, а не быть статической. FDS>Кроме этого, даже если брать один автомат, тогда нужно где-то хранить данные, к нему привязанные. В т.ч. хранить данные для вложенных автоматов.
Данные хранить можно в классе в котором определяется автомат, но сложные вещи как ты сказал выше без поддержки компилятора библиотеки невозможно, есть библиотеки для работы с сетями петри, посмотри может пригодяться, я же не хотел выходить далеко за семантику UML, какие то простые вещи можно сделать, остальные могут только загрузить автомат
FDS>Вообще, я так подумал, это довольно сложно сделать. По-сути надо тогда синтаксис делать расширяемым, грубо говоря, с возможностью написать нечто типа некоторое_слово[параметры] и затем передать это через рефлексию в функцию с именем некоторое_слово со списком параметров, которые она сама будет парсить. И при этом это уже тогда получается автомат сам, наверное, надо менять, чтобы количество параллельных состояний было ограниченным лишь количеством объявленных состояний.
это все сначала надо продумать как должно быть, может быть и возможно сделать DSL для сетей петри, и удобную библиотеку, но я в них не разбираюсь и не знаю как их реализовывать в библиотеке
CU>>у меня в каждом регионе независимое начальное состояние, которое должно указываться там же, эта запись конфликтует с синтаксисом fork перехода
FDS>Странно, конечное состояние, общее для параллельных регионов, есть, а начального нет... по идее, должно быть такое состояние, а эта запись тогда есть fork-переход из него. Ну раз нет, значит не надо, но вообще, гораздо проще его было бы задать как я написал, чем задавать отдельно вручную для каждого региона (если отключить флаг автоматического определения начального состояния).
конечное состояние не общее а каждое в своем регионе, просто конечные состояния не объявляются явно, а переход в конечное состояние подразумевает что в этом регионе или в этом композитном состоянии объявлено конечное состояние, которое и добавляется закулисами, потому что переход в конечное состояние из других подсостояний по словам стандарта бессмыслен
FDS>Я так понял, что final — это ещё одна форма записи конечного состояния. Это не так? FDS>Согласен, экономия в пару символов ничего особенного не даёт.
экономии нет, а проблемы в парсере возникают, пусть лучше будет однообразный синтаксис, можно придумать короче если понадобится, меня пока запись $0 устраивает
CU>>конечно приятно читать, я пометил сделать такой синтаксис, в парсере по идее не должно быть проблем, надо будет просто потом обрабатывать дерево после парсинга и парсить по другим правилам
FDS>Ну да, просто, честно говоря, я не очень понимаю, как такое в PEG правильно сделать — чтоб он табуляции считал.
честно говоря и я толком не знаю как реализовывать indentation синтаксис в PEG, но думается можно это сделать если несколько символов пробелов или табуляций считать спец разделителем, получится дерево, которое надо будет потом обработать и преобразовать в конечный вид, кажется так
Так что не в этом дело.
