OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 23 Октябрь, 2018 13:06

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 43 ]  На страницу 1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 08 Май, 2017 02:28 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9011
Откуда: Россия, Орёл
ANSYS-овское подразделение Esterel, технология SCADE, сфера применений в авионике и железнодорожных системах очень обширная.

http://www.modern-avionics.ru/Files/05- ... 8.2015.pdf

Собственно, мы тут уже обсуждали, что всё идёт к тому, что в центре разработки - системная модель (при этом единая для разработчиков СУ и для системных инженеров),
а от неё уже идёт проектирование СУ и порождение кода (автоматическое или частично автоматическое).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 08 Май, 2017 02:56 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9011
Откуда: Россия, Орёл
Там у них, конечно, довольно ограниченный формализм описания поведения: КА + dataflow.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Май, 2017 14:09 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1067
Откуда: СССР v2.0 rc 1
Ну, хоть какой-то формализм есть.
Что мне странно, вроде всё правильно делают (сверху вниз), серьёзный формальный подход, процедурный уклон, но: этап анализа можно пропустить. И заказы просто жесть: Блэк Хевк, Чинук и Су-35))) Это как?? Мне одному это кажется странным, или у капитала родины нет?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Май, 2017 18:30 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 708
Откуда: Киев
Будешь сильно перебирать с заказами - обанкротишься.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Май, 2017 09:52 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 372
Илья Ермаков писал(а):
Там у них, конечно, довольно ограниченный формализм описания поведения: КА + dataflow

Вот именно.

При этом - весьма сильный маркетинг и PR. Плюс - наличие развитой сети представительств по всему миру, поддержки и пр.
Наличие сертификатов, документации, и прочая, и прочая. Это - несомненный плюс.

Но возникает еще один серьезный вопрос: управление в реальном времени, особенно в авиации и космонавтике - критически важные технологии для государства. Насколько мы можем ориентироваться на иностранные решения? Особенно стран НАТО?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Июнь, 2017 19:54 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Илья Ермаков писал(а):
Там у них, конечно, довольно ограниченный формализм описания поведения: КА + dataflow.


Очень мощный формализм, где есть чему поучиться. К примеру:

Современная интерпретация esterel-"императивщины":
http://ceu-lang.org/
https://vimeo.com/97687022

Для "Lustre"-like "декларативщины" не чужда и явная асинхронность (кроме "автоматом"):
https://www.di.ens.fr/~pouzet/bib/emsoft12.pdf

с модификацией данных по месту (т.е. без лишнего копирования):
http://www.di.ens.fr/~guatto/papers/lctes12.pdf

явно управляемая "n-synchronous":
https://www.lri.fr/~mandel/papers/Mande ... C-2012.pdf

"шедулинг":
http://www.cristal.univ-lille.fr/~forge ... -SAC10.pdf

гибридный автомат:
https://www.di.ens.fr/~pouzet/bib/hscc13.pdf

семантика "интервальных" процессов:
https://hal.inria.fr/inria-00074157/document

Причём такие штуки как Lucid Synchrone показывают, что dataflow-"декларативщина" вписывается в императивный язык (в данном случае -- "уравнения" в ML (оператор where) расширяются до семантики Lustre).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Июнь, 2017 21:04 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9011
Откуда: Россия, Орёл
Спасибо, посмотрим.

Вообще, технологии, основанные на выделении состояний - это хорошо.
Но с примитивными КА не всё гладко. Как только начинаешь разделять состояния МОДЕЛИ управляемой системы и внутренние состояния самой управляющей системы...

Т.е. вопрос развития этих подходов стоит.

Вы же приводите как раз уже нечто другое, чем Эстерелевские диаграммы состояний.
Полноценные языки программирования.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Июнь, 2017 21:32 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Илья Ермаков писал(а):
Вы же приводите как раз уже нечто другое, чем Эстерелевские диаграммы состояний.
Полноценные языки программирования.


Откровенно говоря, у меня нет однозначного понимания, о каких именно диаграммах идёт речь. Я не пользователь и не знаток именно SCADE-инфраструктуры. Esterel-платформу изучал не для задач embedded как таковых, а в контексте обычного программирования "общего назначения" (из-за разборок с "реактивными" фреймворками).

Не знаю всех деталей, чего там у них сейчас рисуют в рамках стандарта SysML (к тому же, если помните здешние дискуссии, у себя на борту имеется предпочтение Р-схемам Вельбицкого). Раньше у них был (ну и есть) свой формализм -- SyncCharts (м.б. и SysML "подлатали" на свой лад):
http://www-sop.inria.fr/members/Charles ... 200324.pdf

где, фактически, "рисуется" императивный текстовый язык Esterel. На глаза попадались также всякие типовые квадратики, символизирующие автомат, со стрелками для передачи данных (в квадратики м.б. вписан непосредственно код).
В любом случае, насколько я понимаю, сейчас тамошние любые рисовалки (для автоматов) по сути генерируют Lustre-код (в основном, и это условно, конечно же). А языки программирования там ещё с 80-х, где основные: Esterel, Lustre и Signal -- DSL, с которым работают программисты с инженерами.
Небольшой исторический экскурс:
http://www.esterel-technologies.com/abo ... ackground/

Общий краткий обзор:
http://www-verimag.imag.fr/~halbwach/PS/iee03.pdf


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Июнь, 2017 21:34 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Илья Ермаков писал(а):
Т.е. вопрос развития этих подходов стоит.

Откровенно говоря, тут вопрос не то, чтобы в развитии, а хотя бы как-то доползти до уровня французской реактивной школы 80-х годов. Тут как раз просто кричащий пример "прогресса" всей "мейнстрим"-индустрии за такой период (в самом широком смысле).
Вы затрагиваете действительно важную тему (если я правильно понимаю ваши тезисы), попробую поделиться конструктивом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Июнь, 2017 21:37 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Илья Ермаков писал(а):
Но с примитивными КА не всё гладко. Как только начинаешь разделять состояния МОДЕЛИ управляемой системы и внутренние состояния самой управляющей системы...

Видимо, под примитивным КА, подозреваю, имеется ввиду та программная техника автоматов, которая напоминает "желелезную" их реализацию (в те времена, когда их количество ещё не измерялось миллиардами). Как школа Шалыто или UML-стандарт, к примеру (да и различные предложения насчёт Дракон-а). Можно взглянуть на "каноническую" реализацию в Boost-е стандарта UML:
http://www.boost.org/doc/libs/develop/l ... ml#d0e1462

где как раз макросы для transition table отражают семантику UML-диаграмм (к слову, в UML, где на первый взгляд вроде как всё гибко и декларативно, нет даже чёткого определения момента, когда считать состояние "переведенным").

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Июнь, 2017 21:44 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Язык Esterel -- обычный императивный язык, где параллельные процессы -- "trail" -- взаимодействуют через "сигналы" (разделяемые переменные). Параллельны они в том смысле, что совместно ожидают "ввод/вывод" (т.е. это конкурентные процессы, корутины, фибер и т.п., фактически, это высокоуровневая надстройка над базовыми средствами реализации корутин). Trail c "вытеснением" -- условиями прекращения работы параллельных процессов (переходы автомата) -- образуют КА. В графических формализмах аля SyncCharts эти "трейл"-ы квадратиками обводят для наглядности.

Штука, как я понимаю, в мире embedded известная (я, всё таки, не спец в этой сфере). Ибо имеются даже железные виртуальные машины для прямого исполнения Esterel-примитивов, вида:
http://jes-eurasipjournals.springeropen ... 009/610891

Но технология не лишена недостатков, к примеру, сложность реализации/эффективной компиляции. Имеются подражания, как ниже -- некий компромисс аля UML <-> аля Esterel:
http://ziyang.eecs.umich.edu/~dickrp/id ... chines.pdf

Или вот под влиянием SCADE в т.ч.:
https://orbilu.uni.lu/bitstream/10993/2 ... an-MDD.pdf

Здесь упрощённый вариант Esterel-примитивов (где как раз хорошо видна базовая сущность, для чего весь этот цирк нужен):
https://hal.inria.fr/hal-00786378/document

Далее я акцентирую внимание на том контексте, где техники Esterel-конторы применяются в отношении любого программирования на типовом императивном языке. Примитивы Esterel-языка, например, используются в таких проектах, как
ReactiveML: http://rml.lri.fr/
FunLoft: http://www-sop.inria.fr/indes/rp/FunLoft/

которые по-своему интересны рядом принципов. Ранее я обращал внимание на проект Ceu (http://ceu-lang.org/), где удачно "вкурили" вкусности Esterel-императивности. Подробности там в manual и аcademic papers. Причём на борту адаптация к динамическим процессам-акторам (автоматам) -- как в Erlang или "go-функции" в гугловском Go, при этом подразумевается техника без GC. Есть отличия от исходной семантики. К примеру. Разделены как бы внешние каналы (там это input, output) и внутренние события (event) -- на каждый вход от условно внешней среды выполняется множество всех внутренних событий (техника ближе к современному пониманию аля event driven). Нельзя делать опросы в принципе вида "а есть ли сигнал такой-то в данный момент ?". В Esterel есть конструкция для опроса (present), но отбрасываются компилятором зацикливание вида "если есть сигнал А то ... иначе emit A" (язык Esterel изначально проектировался для создания "железных" цифровых схем, где необходимо анализировать состояния входов). В языке FunLoft (выше по ссылке, это как бы альтернативная линия для экспериментов вокруг самой Esterel) в подобных случаях делают блокировку -- вводят виртуальные такты автомата, процесс приостанавливается, пока не отработают все операции с сигналами, затем восстанавливается опрашивающий как бы в уже новом виртуальном такте автомата -- на мой вкус, неудобное поведение.
Т.е. в Ceu, хоть там по примерам вся работа осуществляется на разделяемых переменных, на самом деле внедрена универсальная семантика ввода/вывода, включая внешний (в т.ч. устройства/файлы и т.д.), или же "анонимный" . Могу рекомендовать взглянуть на технику корутин через "анонимные" каналы -- в языке Felix ("скриптовый" язык, дающий на выхлопе код на С++ -- альтернативная велосипедная (но толковая) реализация С++):
http://felix-lang.org/share/src/web/tut ... index.fdoc

Т.е. в Ceu "полноценные акторы", могут общаться внешне, быть асинхронными (ну и как для "бейсика", в Ceu на борту предлагают типовые парадигмы асинхронности (реальной параллельности) вокруг shared variable).

В Ceu "сильные и слабые вытеснения" trail-ов реализуются самой конструкцией "параллелизма" (вместо Esterel-операторов "abort ... when ..."), ну и такая же стековая дисциплина (плюс помогалки-обвёртки вида watching).

Здесь примечательным будет сравнение подходов с современным мейнстримом в лице того же Go, который реализует те же акторы и на том же CSP-исчислении. Нужно сопоставить "диспетчеризацию" на основе Go-шного оператора "select" (где "case"-секции ожидают на операциях с каналами, тем самым, фактически, реализуется семантика известной одноименной unix-функции) с операцией аля:

par/or do
...
with
prepare;
sel_ch, chans = select_rr(chans);
...
end;

где второй trail будет выполнен только в случае, если первый trail окажется в ожидании на каких-то своих операциях (в Esterel в отличие от Go -- строгий порядок). При этом здесь используется какая-то своя семантика опроса каналов -- select_rr -- выборка по принципу round robin: сработавший канал во входном массиве улетает в конец, функция возвращает измененный массив и выбранный канал. А некая связанная предварительная операция подготовки prepare, по сути, будет выполнена только, если операции ввода/вывода "неудачны" в первом trail.
Короче говоря, в Esterel, в отличие от Go, акцент на управлении именно процессами. Это просто нужно прочувствовать, и это глобальная линия во всех технологиях (именно в этом сила "мощности формализма").

И, кстати, насчёт "стадий" message passing. В функциональной среде известна библиотека Concurrent ML (её принципы портируют во многие вещи):
https://pdfs.semanticscholar.org/0fe7/3 ... 88ce45.pdf

Там как раз выделяются понятия событий, предварительных и пост-стадий и т.д. Традиционная техника на комбинаторах (лямбдах) для декларативного построения сложных протоколов. Можно попытаться слепить идентичные алгоритмы в стиле "убогая императивщина 80-х" VS "Haskell-классика" и сопоставить (в дополнение ещё можно воспользоваться всякими расширениями для Concurrent ML типа "транзакции" и др., т.к. базовых примитивов явно не достаточно для реального применения).
В Ceu, кстати, понимают "в чём прикол". К примеру, их вынужденная конструкция "traverse":
http://www.ceu-lang.org/chico/ceu_rebls15.pdf

Однако, "функциональщину" никто не отменяет (она есть даже в hard realtime Esterel-платформы) там, где она удобна и к месту.

Итого, уже в 80-х в Esterel занимались ликвидацией того, что сегодня "гордо" называют паттерном "наблюдатель" и связанный с ним callback hell. Всё направлено на то, чтобы максимально оставаться в русле структурного программирования (замыкать состояние, быть поближе к простым последовательностям, развилкам да циклам).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Июнь, 2017 21:53 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Тем не менее, хоть управлять "хаосом" неизбежно нужно, но и в стиле примитивов языка Esterel это тяжело, и, прежде всего, для задач именно dataflow. Достаточно взглянуть на демки того же Ceu (к примеру фиг.9):
http://www.ceu-lang.org/chico/ceu_rem13_pre.pdf

Для случаев условно "не анонимности" появляется возможность автомат "локализовать" в виде функции, явно выделив его входы/выходы в виде аргументов/результата функции. Автоматы-функции ("акторы") организуются как в обычном коде, формируя иерархические КА. Появляется возможность явно выделить понятие "такта" (у них там это clock). Изначально такая явная "dataflow"-модель в виде языков Lustre и Signal использовалась для типовых расчётных задач, числомолотилок, или аля аудио/видео декодинг и т.п. Но, в целом, ранее был представлен Prelude с целым "шедулингом". Или вот для управления "хаосом":
https://hal.inria.fr/hal-01509314/document

Опять же, я не трогаю embedded специфику. Уделю внимание универсальным концепциям, подходящим для всех "смертных".

Как пример впихивания Lustre-семантики в обычный императивный (ну и функциональный) ML -- язык Lucid Synchrone
https://www.di.ens.fr/~pouzet/lucid-syn ... manual.pdf

Изначально языки Lustre и Signal имели чуть разную семантику (ну, отличается и синтаксис, и чуть разный подход в организации базовых конструкций). Сейчас же с учётом всяких расширений можно сказать, что принципиальная разница стёрта. Lustre изначально позиционировался для числомолотилок, отсюда для упрощения требовалось, чтобы все входные аргументы всегда как бы были указаны (как при вызове обычных С-функций, т.е. не было опциональных данных, хотя косвенно таковы подразумевались. За подробностями -- лучше в ориг. доки). А Signal проектировался для выражения "железных" автоматов -- функция должна "реагировать" как только на входе покажутся необходимые данные (необязательно все, название "signal" -- как выражение отношений между сигналами). И сейчас весь код в Lustre-like строится так, чтобы не было строгой необходимости явно указывать отсутствие данных (и, в целом, тамошние языки проектируются выдавать на выхлопе не только C/C++/Java/байт-код и т.п., но и HDL-спецификации железа или какой там нужен формализм для платформ). С учётом поддержки гибридных автоматов, фактически, полностью покрывается семантика агрегатов Бусленко.
В основе для critical hard realtime жёсткие ограничения для базовых возможностей. Это заметно, например, по таким вещам, как работа с массивами (статические, и других контейнеров нет. Кстати, тут есть и удобная "функциональщина"):
http://laure.gonnord.org/pro/research/E ... arrays.pdf
https://link.springer.com/content/pdf/1 ... F59130.pdf

Тамошние "node" в Lustre-языках выглядят как:

Код:
node sum(x: int) = (y: int)
let
  y = x + (0 fby y);
tel


что, по сути, можно трансформировать в такой класс (аля Java):

Код:
class Sum {
  int m_y;
  void reset() {m_y = 0;}
  int step(int x) {
    int y = x + m_y;
    m_y = y;
    return y;
  }
}


Т.е. в языке обычные функции -- комбинаторные автоматы (без состояний), а "node" -- те же функции, но с состоянием ("побочными эффектами"). Исходный рабочий код потом перестраивается под платформу. Т.е. там, где, к примеру, есть вызов ф-ции аля "a = sum(x, y)" на самом деле будет построен "функтор" (в терминах С++). Однако, в отличие от библиотечных фреймворков в мейнстриме для реализации всяких автоматов/акторов и прочей "реактивности" здесь не используются какие-то явные списки/графы акторов или зависимостей по сигналам и во время runtime по ним гоняются данные. Во время compile time выявляются все зависимости, всё "инлайнится", оптимизируется и т.п.
Что не мешает и реальному "ООП":
https://pdfs.semanticscholar.org/f570/9 ... 83acca.pdf

В статье выше есть примечательный момент -- использование оператора "last". В Lustre подразумевается, что при каждом вызове (такте) всегда данные должны быть актуальными. Т.е., как в обычном императивном языке компилятором отслеживается использование неинициализированной переменной, здесь этот подход расширяется на каждый такт автомата. Опциональные данные могут быть оформлены в виде спец-типа вида "signal[t]" или "sig[t]", что соответствует типовому ATD вида "Option[t] = None | Some[t]". Чтобы не заниматься по требованию компилятора каждый раз проверкой, используют оператор last -- последнее значение, полученное неважно когда. К примеру:

Код:
let some_proc(...) = res where
{
    init a = 0;
    ...
    res = any_func(last a);
}


(кстати, в ML-like "уравнения" вида "where ... and..." лишь для удобства когда нужно, чтобы не лепить явно последовательность через ";"). Или для входного аргумента:

Код:
let some_proc(a: sig[int] ...) = res where
{
    last a = 0;
    ...
    res = any_func(last a);
}

что означает "установить "а" в ноль, если в первом такте не было данных". Для явной проверки кроме типового "match ... with ..." есть конструкция "present" (чтоб не возиться с явными Some|None "классическим" способом):

Код:
present
| A(x) && x > 0 => emit Q = some_proc(x)
| A(x) && B(y) && x <> y =>
    do
      ...
    until C(v) && v > 0 // "интервальная логика"
end


Семантика конструкции "явных" автоматов ("automaton" или "mode" в док-ах) подтверждает "Esterel-процессный" подход:

Код:
let switch(low, high) = o where
  mode
    |Init -> do o = 0 until low(val u) then Up(u)
    | Up(u) ->
        do o = last o + u
        until high(val v) then Down(v)
    | Down(v) ->
        do o = last o - v
        until low(val w) then Up(w)
  end


где процесс имеет одно поведение, при наступлении какого-то условия процесс меняет поведение, т.е. на тот же вход реагирует по-другому. Есть слабое "вытеснение" -- оператор until -- автомат должен выдать результат и затем при потребности перейти в новое состояние, и сильное -- unless -- переход в другое поведение перед началом такта. Для перехода есть и оператор continue (продолжить или возобновить состояние), then означает "сброс" в начале (т.е. работать каждый раз сначала).
Для "сброса" также есть оператор вида "reset ... every ...", что означает "сброс" по всей иерархии "нод"-ов.

Фактически, "потоковая" Esterel-модель является альтернативой таким как Sigma-C и StreamIt:
http://www.cs.ucy.ac.cy/dfmworkshop/wp- ... essors.pdf

но семантика и возможности значительно шире. К тому же в формализмах выше "ключевые слова" и прочие спец-конструкции лишь "протокол о намерениях" -- нет возможности полного контроля сопровождаемого С-кода.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Июнь, 2017 21:57 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Уточню насчёт взаимодействия автоматов. Понятно, что у платформы есть средства для контроля, тестирования, верификации и т.п. (в т.ч. и спецрасширения для языков, позволяющие программировать прямо "online"). Правда, не всё так уж и "шоколадно" (но таковы особенности любой верификации в целом):
http://www-verimag.imag.fr/~halbwach/PS ... -71-87.pdf

Но речь не об этом. В статье про "Lustre-объекты" (в пред. посте) есть крайне важная штука -- "шедулинг" самого объекта-автомата, т.е. установление допустимой последовательности вызовов методов в его интерфейсе. Причём это часть автоматического вывода типа в ML-стиле (к тому же уже базовые средства компилятора неплохи для выявления многих случаев deadlock-ов и livelock-ов -- чем и хороша "потоковая" модель). Поскольку "node" и "объекты" замкнуты "в себя", их можно "разрывать" как угодно. К примеру, проектируется группа взаимодействующих автоматов, в т.ч. можно и через упрощения (тестированием, эмуляцией и т.п.). В итоге автоматически сформировали "библиотеку" с интерфейсами. Теперь можно реализовывать какую-то реальную систему, где эти же автоматы будут пусть какими-то "распределенными" (с дополнительной обвязкой для сетевого ввода/вывода), как будто типовые акторы в стиле Erlang/Go. Но, на борту уже есть протоколы и средства для их контроля.

А если "типовые акторы" проектировать "по-типовому", т.е. "с нуля"? Ну, типовой подход -- таймеры для отлова глюков (если возникнет deadlock/livelock/перегруз), и для выявления технических проблем. А если нужны протоколы, да контролируемые средой, да ещё желательно compile time?

Кстати, насчёт перегрузов/недогрузов -- опять же в той школе:
https://hal.inria.fr/hal-01425902/document

В мейнстриме есть техники вида "typestate". В Rust-е это умерло:
http://pcwalton.github.io/blog/2012/12/ ... e-is-dead/

Было, например, в проекте Vault от MS (экспериментальное расширение С):
https://www.microsoft.com/en-us/researc ... pldi01.pdf

Есть "session types", в т.ч. и "Multiparty":
http://simonjf.com/2016/05/28/session-t ... tions.html

В общем, можно сопоставить подходы.

Примечание. Компилятор может отслеживать "протокол" автомата лишь в замкнутом коде, как в статье про "Lustre-объекты". Но возможны техники runtime "разрыва/восстановления" типа. К примеру, можно взглянуть на академическую реализацию "сессионных типов" для Java (см. вокруг typecase и др.):
https://www.doc.ic.ac.uk/~rhu/sessionj/ ... safe10.pdf


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Июнь, 2017 22:02 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Теперь любопытно взглянуть на сложившиеся подходы по обработке ошибок. В языке при наличии Esterel/Lustre примитивов есть всё для организации координации "верхнего уровня". А рядовую чёрную императивную работу в этом случае удобно делать через exception -- в стиле "ваяем как happy path, exception прервёт". Тем более сейчас это довольно эффективно:
https://habrahabr.ru/post/267771/

В мейнстриме же сейчас толком не знают чего делать -- отказываются от exception и в то же время они есть (Rust, да и Go). Когда возникает потребность в "логике верхнего уровня", то мечтают о "conditions and restarts" из CommonLisp:
http://axisofeval.blogspot.com/2011/04/ ... o-you.html

Или пытаются реализовать:
https://static.rust-lang.org/doc/0.8/tu ... conditions

В Scala лепят "continuations":
http://www.scala-lang.org/old/node/2096

Или вот статья:
http://ajc.su/koding/budushhee-programmirovaniya

где я лишь обращаю внимание на замечание про "опциональная ленивость в Scala не справляется" (плюс там ссылка на подробности) -- это всё про координацию "верхнего уровня".

И мода на "реактивные" фреймворки в мейнстриме -- "не то пальто" совсем. Там не понимают самой главной сути...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Июнь, 2017 22:04 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Итого. До "довольно ограниченных формализмов" 80-х в мейнстриме ещё очень и очень далеко. Увы...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Июнь, 2017 11:26 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9011
Откуда: Россия, Орёл
Ещё раз большое спасибо, очень много информации к размышлению.
Надо покопать ваш материал :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 04 Июль, 2017 23:06 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 372
Илья Ермаков писал(а):
Там у них, конечно, довольно ограниченный формализм описания поведения: КА + dataflow.

Вот именно!

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 07 Июль, 2017 20:53 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Презентация -- генерация кода из моделей в SCADE:
https://www.react.uni-saarland.de/teach ... 2010-W.pdf

Действительно, в основе графические Safe State Machines, что по сути есть SyncCharts (раньше была ссылка на док-ю). Так реализуется семантика текстового Esterel. А текстовый язык -- ограниченный Lustre, примитивы которого также и "рисуются".
Видимо, в Airbus-е и Ко (под крышей которых вся эта Esterel выращивалась) жизнь веселее. Но я не в курсе, чего там могут поставлять в рамках SCADE (к тому же вопросы стандартизации, сертификации и пр. здесь не на последнем месте).

Но ограниченность, всё-таки, условна. К примеру, отсутствие явных циклов аля оператор while компенсируется примитивами аля map/reduce/fill и пр. (что м.б. даже удобнее, но это при работе с массивами). Рядом с ограниченным Lustre есть расширенный Lutin:
http://www-verimag.imag.fr/DIST-TOOLS/S ... andout.pdf

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

А, в целом, платформа толково развивается. К примеру -- Liquid Clocks -- внедрение техники "liquid types" -- зависимых типов:
https://hal-mines-paristech.archives-ou ... 3/document

что позволит в таких языках как Lucid Synchrone контролировать (но ограниченно) и ML-"императивщину" (да и "функциональщину", т.е. не только "уравнения" Lustre-like). В итоге часть функционала, который подключается в виде "внешних" FFI-функций на С/C++/Ada/Java/чего там нужно, можно будет реализовывать в одном языке, под общим "надсмотром".

Тамошнее базовое понятие этих "clocks" выглядит не так уж и бедно (в т.ч. и явное манипулирование периодами и частотами, сдвигами, задержками, over-sampling и under-sampling, теоретико-множественный подход и пр.). Как-то не наблюдается возможных преград для расширения примитивов, если требуется добраться до уровня исчисления "управляющего автомата реального времени", как оно было когда-то представлено на сайте ГрафКонта (примитивов в стиле: синхронизация не только по началу, но и по концу, запуск строго позже, и пр. абсолютные и относительные временные операции). Я не в курсе всех тамошних техник "шедулинга" (детально не разбирался), но ведь такие задачи там тоже решаются (к тому же есть техники "разделения" кода -- автоматы "распределяются". То, что раньше выглядело обычной передачей аргументов в функции, "трансформируется" в новые подсистемы управления/доставки данных, которые должны соблюдать определенный ранее инвариант. Т.е. первичный код -- как протокол взаимодействия). Есть и упрощенные модели, как "affine transformations" этих "clocks":
http://citeseerx.ist.psu.edu/viewdoc/su ... .1.25.6139

Кроме понятия "синхронности/асинхронности" есть и "квази-синхронность" или "квази-периодичность":
https://www.lri.fr/~mandel/papiers/Halb ... D-2006.pdf
https://tel.archives-ouvertes.fr/tel-01545630/document


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 07 Июль, 2017 20:56 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Кстати, на embedded в мире "функциональщины" тоже обращают взоры. Есть проект Hume:
http://www-fp.cs.st-andrews.ac.uk/hume/index.shtml

Похоже, не развивается, и, конечно же, это лишь академические работы как попытка найти практическое применение наработкам из проекта Idris. "Ленивость" не используется, т.к. "противопоказана" недетерминированность вычислений.

Есть интересные задумки, к примеру, реализации автомата. Расширяется способ обработки pattern matching (особая альтернативная политика для сопоставления с образцом в рамках верхнего уровня функции). При выполнении функции как бы фиксируется позиция сработавшего условия в pattern matching, затем при следующем "такте" сопоставление начинается не с начала (сверху), а с прошлой позиции.
В общем, любопытно, но стрёмно. В Esterel таким не практикуют, да и семантика там шире и удобнее.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 07 Июль, 2017 21:01 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
И вновь насчёт современного мейнстрима. Esterel-платформа яркий к нему симптом. К примеру, сейчас в рамках стандарта С++ ведутся дискуссии по внедрению корутин/асинхронности на уровне языка:
https://habrahabr.ru/post/278267/
и смежная статья: https://habrahabr.ru/company/infopulse/blog/203724/

где под влиянием Microsoft пытаются протолкнуть языковые средства под ключевыми словами "async/await, resumable/yield", мотивируя необходимостью реализации оптимизаций на уровне компилятора (библиотечными средствами не всё возможно, и это правильно и необходимо). Противники утверждают, что есть огромный опыт применения уже действующих библиотечных средств для низкоуровневой реализации корутин/асинхронности, которые в т.ч. позволяют обеспечить и иные высокоуровневые парадигмы взаимодействия, чем у "видения" MS. В самом деле, "корутины" предполагаются как типовые "попсовые генераторы" аля:
Код:
sequence<int> range(int low, int high) resumable
{
    for(int i = low; i <= high; ++i)
    {
        yield i;
    }
}

Достаточно сравнить с уровнем их понимания у Esterel, их "автоматы-функции".

А ранее уже была ссылка на реализацию "async" в Lustre:
https://www.di.ens.fr/~pouzet/bib/emsoft12.pdf

"Async" в таком языке как Lucid Synchrone может дополнить базовую "императивную" futures, предлагаемую в С++.
Чем полезны "уравнения". Не важно как инициируется функция-автомат, пусть динамически аля spawn, но уравнения рядом с императивом контролируют всю иерархическую структуру процессов (во всех вложенных автоматах). В дополнении к тому, что указано в статейке выше (там, кстати, лишь вскользь указано о приоритетах процессов, привязке к виртуальным процессорам-исполнителям), вполне возможна произвольная техника организации всего конвейера. К примеру, прозрачно внедрить общий кольцевой буфер для передачи данных, если так эффективней работать с памятью.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 43 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB