Моделирование конечных автоматов-2

Я так понял, что вы хотите иметь некую программу для задания регулярных языков через рисование графа КА и наглядного тестирования распознаваний этим КА конкретных предложений, показом первого зафейлившегося символа.

Проблема в том, что такое ПО не имеет смысла за пределами образования в рамках соответствующего курса по формальным языкам. И там оно тоже особого смысла не имеет, потому что:

1. люди просто рисуют конкретный КА и на бумаге или доске ищут ошибки. В крайнем случае пишут скрипт на питоне или в октаве, если лень рисовать кружочки.

2. КА - не самое сложное, что есть в курсе, потому что это всего лишь регулярные языки, и если у студента проблемы уже на этапе понимания их, то как он будет учиться дальше, когда пойдут всякие магазинные автоматы, контекстнозависимые языки, МТ…

В индустрии, когда нужно реализовать конкретный КА - это тоже особо не нужно, потому что:

1. код распознавалки с КА будет каждый раз разный (другой распознаваемый язык, другой ЯП, другой ввод/вывод);
2. если тестирование конкретных предложений имеет важный смысл для контроля качества, то в любом случае, для кода КА создаются юнит-тесты.

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

А тех, кто внедряет подобные «помогалки» сверху - травить любыми доступными способами, но, коль скоро нельзя отправлять подобных «прогрессистов» в биореактор, проще всего саботировать такое вредительство со стороны дурачков от образования.

Изучение «помогалог», на самом деле, разжижает мозг и отвлекает от изучения собственно сложных вещей. А если студент не может понять КА, он выбрал не ту специальность.

Есть ощущение, что вы меня поняли как-то превратно и начали с этим своим пониманием спорить.

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

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

Изучение «помогалог», на самом деле, разжижает мозг и отвлекает от изучения собственно сложных вещей.

Давайте уж в машинных кодах прогать, к чему все эти сишки с хаскелями. Навыдумывали похабщины!

Опять таки, вот эти «описание», «использование», «рисование диаграмм» - каждый будет реализовывать по-разному, и то, что уже кто-то сделал на коленке, вам, скорее всего не понравится.

Я бы посоветовал реализовать всё самому. Берётся python-lark. На нем описывается грамматика для интерпретируемого языка. Каждое предложение на языке интерпретатора парсится ларком, он строит дерево AST. По этому дереву интерпретатор проходится и выполняет команду. Визуализация в простейшем случае отсутствует, интерпретатор будет просто показывать результат «выполнения» КА на конкретном предложении.

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

Это что проблема? Зачем ограничиваться наколенными поделками? Даже если на коленке, из двух поделок выберу ту, которая больше понравится. Вам нравится грамматика и синтаксис <любой ЯП>? Нет, тем не менее используете и не бздыкаете.

Берётся python-lark. На нем описывается грамматика для интерпретируемого языка.

даблфейспалм.жпг

Конечно можно все сделать самому, но зачем если уже кто-то это сделал?

Конечно можно все сделать самому, но зачем если уже кто-то это сделал?

Откуда такая уверенность?

даблфейспалм.жпг

что, не нравится сложность? Тогда просто задаём схемы для JSON файлов двух видов: 1) задание языка КА; 2) задание теста. Дальше пишется скрипт на питоне, который читает 1) и генерит код.

не нравится сложность?

Тогда просто задаём схемы для JSON файлов двух видов: 1) задание язы

Не нравится уверенность, что ничего нет, нужно делать самому. Если вы про это ничего не знаете не значит, что этого нет.

Откуда такая уверенность?

Нет уверенности. Так же как нет уверенности в том, что этого нет.

За спрос в глаз не дадут, это я понимаю. Но у меня тоже сложилось впечатление, что вы хотите странного. А значит надо самому городить.

Предыдущая ветка закончилась тем, что ничего нет, надо делать самому.

В предыдущей ветке упоминали Graphviz, чем он не подходит?

У меня на руках прямо сейчас проект электронного орга́на, где с помощью Graphviz написана текстовая портянка, а из неё fsm, которая используется в программе. И есть красивый рисунок.

что вы хотите странного.

Разве? Я хочу формальный язык в котором можно было бы описывать входные значения (например булевые), выходные значения (тоже булевые), состояния (набор булей). Логические условия для переходов (not, or, and). Чтобы это все имело строгий синтаксис, однозначную семантику. Чтобы он был простым, компактным и наглядным. Это первый этап.

Дальше хочу чтобы на этом языке описать желаемое поведение. И дальше по этому описанию получить:

• диаграмму переходов (например через graphviz)
• таблицу состояний
• код на популярном ЯП который будет строго делать то, что описано.

Это что странное? Все программирование от асм до coq состоит из этого.

В предыдущей ветке упоминали Graphviz, чем он не подходит?

У графвиза все заточено под описание графов. Только ребер и вершин, а дальше все это обмазывается атрибутами для красивого отображения.

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

А мне нужен язык для предметной области, из которого можно было бы получить dot-файл (откинув лишнее и преобразовав в атрибуты и текстовые метки).

Вспомнился ДРАКОН. Но это скорее шутка.

А мне нужен язык для предметной области, из которого можно было бы получить dot-файл

Выглядит как очень интересная задачка.

А можете написать некий псевдокод, чтобы было представление как этот язык должен выглядеть?

е написать некий псевдокод, чтобы было представление как этот язык должен выглядеть

Даже не знаю. Я не спец по языкам. Ну если исходить из математической нотации:

x[n] - входной сигнал (вектор)
s[k] - состояние (вектор)
y[l] - выходной (вектор)

// изменение состояния
s[0] = (x[0] and x[1]) or s[2];

// изменение выходного сигнала
y[1] = s[0] or x[3];

// объявление функции (чистая или с состоянием, то есть вложенный КА)
s[3] = f[0](s[0], s[1], x[3]) 

числовые индексы можно и нужно заменить на текстовые метки (#define)

А дальше все это описать на flex (или что там у нас сейчас модное) и забубенить парсер. Возможно, достаточно взять часть какого-то популярного ЯП и просто ограничить его. Так как это не моя предметная область, я тут не силен в выдумках. Главное чтобы грамматика не была через отступы (сдохни питон!!!).

Вот тут присылали ссылку на такую штуку:

https://plantuml.com/ru-dark/state-diagram

Тоже выглядит весьма неплохо, хотя и тоже тот же graphviz, вид сбоку.

https://www.w3.org/TR/scxml/
оно?
графоний и визуальная отладка тоже есть, но в большинстве под офтопик, отдельными утилитами.

же есть, но в большинстве под о

Похоже, но хотелось бы менее многословное чем XML. Тут важно чтобы писать руками можно было без копипасты, иначе можно в мешанине текста не заметить тупняк.

Может где-то есть локальное изобретение для обучения студентов?

Для студентов достаточно андроидной апликухи Verilog premium IDE & compiler.apk © (google.com).

Хочется какой-то формальный язык заточенный именно под КА.

Рагел подойдёт?

https://github.com/adrian-thurston/ragel

Вообще я не очень понимаю проблему. Языков описания конечных автоматов и моделей их воспроизводящих в том или ином виде пруд пруди. Ясно, что каждый студент по Computer Science на третьем-четвёртом году учёбы заморачивается чем то подобным, поэтому в интернете полно решений. Начиная с

https://en.wikipedia.org/wiki/Finite-state_machine

и там в разделе «языки» и «реализации» прямо по списку.

Вот это смотрел?

https://github.com/jserot/grasp

Еще есть такая штукенция:

Finite State Machine Designer
https://formalsketch.github.io/

Работает онлайн, есть минимизация, есть экспорт.

Симуляция работает, но у меня не получилась пошаговая отладка. Кнопка Step делает один шаг и дальше непонятно как делать следующие шаги.

https://www.jsoftware.com/help/dictionary/d332.htm

There are three dockerfiles that demonstrate installing dependencies and building

Ну-ну…

Что «ну-ну»? Смотрите оригинальный запрос «Хочется какой-то формальный язык заточенный именно под КА.». Формальный язык? Формальный язык! Заточенный под КА? Заточенный под КА! Задание выполнено господин начальник, разрешите отдыхать!

если бы меня бесил питон и не хотелось бы разбираться во всяких плюсах, я реально рассмотрел бы альтернативу в виде Excel. Я не знаю, какой скриптовый ЯП сейчас мейнстрим в ЛибреОффисах, но в Excel - это TypeScript, и вроде как уже с 2016.

Просто пишем описание КА, как по учебнику, в конкретные строки таблицы. Скрипт запускается, прогоняет тесты и генерит код, какой нужно.

Я во втором сообщении написал, что вообще не понимаю проблему. Но ТСу виднее, раз вместо обычного поиска и выбора подходящего он второй раз создаёт тему. Я подозреваю, что у него ещё 35 требований спрятаны в кубышке, про которые ним не говорит, иначе давно вопрос был бы закрыт.

я так понял, что хочет проверять КА и тесты на формальном языке, чтобы:

1. не нужно было это всё программировать на целевом ЯП;
2. обойтись без юнит-тестов целевого кода.

Графический фронтенд - это бонус.

Чушь какая в обоих сообщениях.

Легко могу представить когда было бы удобно иметь исходник таблицы КА - когда нужна формальность, этих самих КА больше десятка или история (git). Изменил исходник, закоммитил, задеплоил - и в документации новая схема, в истории изменения. Для ардуинщиков с автополивом это и вправду не нужно, можно в голове или на бумаге держать.

я вообще за то, чтобы вытравливать все компютерные «помогалки» из обучения

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

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

я так понял, что автор всё и так знает про КА, т.е. с пониманием нет проблем. Но он не хочет программировать эти КА.

он не хочет программировать эти КА.

да, я не хочу писать все эти портянки на любимом ЯП. Все эти тесты и прочее.

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

Когда я это хотел, я на бейсике писал :) если ног у микрухи до сорока штук, ещё туда- сюда. Функция с 40 параметрами.

можно накидать идей как бы мог выглядеть такой язык

Например, вот так https://github.com/ztellman/automat

Всем спасибо за ссылки и идеи. Их оказалось больше чем я могу даже поверхностно посмотреть. Поэтому пока пауза.

Но если будут еще идея, велкам!

чем не годны едино в трёх лицах(пацкаль асмя и какието схемы псевдоэклектические и ещё какойто 4вариант) для stl мэк какойто вся европейская асуча на нёй?

чем не годно вот вот это ваше всё IEC 61131-3 PLC Languages ?

ну ныряй в таблицы решений (https://ru.wikipedia.org/wiki/Таблица_принятия_решений https://en.wikipedia.org/wiki/Decision_table ) по русски последнее из широко тиражного в времена заката коссыгинской реформы и письма Турчина_Медведева_Сахорава в политбюро на предмет что течение несёт на скалы

по английски(по международречске вроде как и у швейцарских гномов тож) вроде как тема жива и есть инструменты

проблема всех вот этих вот нотаций что с какого то момента(когда комбинаторный взрыв состояний прикрытый эффемизмом ram) ни чего лучше программного кода до сих пор не нашли и как результат всё упирается в баланс качества анализа кода и или избыточность ловушек и прочего наворачивания избыточности по принципу хоть какой то контур да сработает - в целом упор в проблему останова

а по серьёзному «мало» задач в которых реально требуется исчерпываюшее покрытие - Дейсктра жи с Хоаром вроде как опытным путём показали не практичность полного доказательства

т.е. если инструменты ваще есть они пока не стали общеинфраструктурными а остаются коммерческими тайнами Ж)

.

https://letmegooglethat.com/?q=Model Checking of finite state machines

,

придумай. посмотри что в индустрии есть для визуального кодирования. я вот прямо сейчас делаю нечто подобное, но не для КА, а для архитектурного (софт) дизайна и визуализации. еще на этапе драфтов, но направление - микс из гантта и сиквенс диаграмм. дсл под это дело - самая простая часть.

ПС С4 не предлагать. с этим работать просто неудобно. но кое-что оттуда подсматриваю. чужие ошибки - кладезь

посмотри что в индустрии есть для визуального кодирования.

Мне как раз визуальное кодирование не нужно вообще! Мне нужна компактная грамматика для описания КА. Максимально компактная, но при этом, чтобы можно было нарисовать парсер (то есть должна состоять из ascii). А дальше уже из нее черпать визуально представление (самое простое) и моделирование (с этим уже сложней), формальную верификацию (это уже рокетсайнс).