Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, _hum_, Вы писали:

__>>Ну, значит, у вас отличное от того же википедийного понимание чистоты функции.
WH>Значит у авторов agda2 тоже не правильное понимание.
WH>У них там функции могут в некоторых случаях принимать аргументы без явного указания их пользователем.
WH>Это очень сильно сокращает код.
WH>У тебя ровно то же самое.
WH>Твой контекст это аргумент функции. Просто функция захватывает его без помощи пользователя.

О! Так может механизм неявного захвата аргументов в agda2 — это то, что мне нужно... Не могли бы вы здесь простенький пример написать, чтобы мне проще было ориентироваться?

__>>Пример. Функция f не имеет побочного эффекта, но в то же время из-за зависимости от контекста не является чистой.
WH>У тебя семантика совершенно другая.
WH>И данный код вообще к делу не относится.

Он иллюстрирует то, что зависимость от контекста все же может портить чистоту функции (потому я и опасаюсь таких вещей).

__>>1) "выражение <expression> преобразуется до тех пор, пока можно, после чего в нем заменяется вхождение всех символов на значения по ситуации <ситуация>", то ли
__>>2) "в выражении <expression> заменяется вхождение всех символов на значение по ситуации <ситуация>, после чего производится его вычисление".
WH>Семантика номер два в твоем случае вообще не имеет смысла.
WH>Ибо когда человек задает контекст, он ожидает, что всё внутри этого контекста будет вычислено с использованием этого контекста.

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

__>Я имел в виду, что ваш вариант от моего отличается настолько же, насколько синтаксический сахар отличается от конструкции базового языка, которую он подменяет (то есть, является практически только "косметическим" средством).
Не стоит не недооценивать "косметические средства", т.к. это то делает синтаксис визуально красивым и интуитивно понятным.
__>Вы же сами признали, что выглядит все жутко.
Это я о том что такие большие выражения вряд-ли встретятся при программировании контроллеров в рамках одной модели. Но по сравнению с предметным ЯП созданным по модели, это действительно жутко.
__>А теперь представьте себе, что эту жуть придется редактировать (а тем более другому человеку).
Это лучше чем редактировать подстановочную абрукадабру, здесь как минимум понятно откуда берутся "a1,a2,a3,..,a10".
__>Даже такая элементарная операция как добавление нового условия наподобие E5: E3 + E2 становится нетривиальной — придется просматривать, какие именно "а"-шки используются в E1 и E2, чтобы правильно указать E5(a1,a2,a3,a6,a7).
Зачем просматривать? Какие передаются те и используются, достаточно посмотреть на определение.
__>Да и вообще, в вашем варианте это не функции, поскольку при определении функции указываются параметры, а не аргументы.
Путь будет параметр
__>В вашем же варианте вы определяете не функции, а правила замены "функциональных выражений" наподобие того, что делается в пакете Mathematica, когда пишется, например, f[1] = 1. А это уже, извините, в школе не проходили, и не так просто для объяснения.
В универе проходили, и школе похожие вещи встречались.
__>Например, как воспринимать запись E1(a1) = a2 как "E1(a1) везде по тексту далее заменяется на a2"?
При компиляции сообщать пользователю: "a2 не является числом или параметром функции E1".
__>Если же настаивать на том, что все "а"-шки, участвующие справа, должны быть указаны в списке "а"-шек слева, то пользователь может задать резонный вопрос — так а зачем тогда вообще этот список ему указывать, если он автоматом определяется по правой части?
Ответ: Это защитит вас от путаницы связанной с не правильным указанием идентификатора и неопределённости его значения, которая может привести к непредсказуемому поведению программы.
__>Во-первых, как там представляются ситуации — векторами или другим образом — не принципиально. На момент написания программы пользователь уже знает, что ситуации заданы, и имеет четкое представление о них. То есть, у него есть вся информация о том, что значит ситуация S0 или S1. Во-вторых, я обозначил значения a1,a2,...,a10 только для удобства. На самом деле эти идентификаторы несут информацию о том, какое значение содержат. Например, "a1" <-> "Pressure", a2 <-> "Temperature" и т.д. Сами же ситуации выглядят наподобие
__>S1 — ситуация при включенном нагреве теном на мощность 200кВт",
__>S2 — ситуация при включенном нагреве теном на мощность 400Вт" и т.п.
Если пользователь знает что у него есть "тен на мощности 200кВт", "тен на мощности 400Вт", "Pressure", "Temperature" etc. Зачем тогда вся эта возня с ситуациями, контекстами, подстановками? ИМХО, пусть пользователь пишет как знает: 'включить "тен на мощность 200кВт" если "Temperature" > 100 и "Pressure" будет > 200'.
__>Те же претензии, что и выше
__>- нужно правильное оформление функций;
Привольно оформленные функции легшие читать.
__>- увеличивается громоздкость (трудно читать и редактировать).
Чтоб редактировать с начало нужно понять, и "громоздкость" ту как нельзя к стати.
AC>>Передавать придётся не весь контекст а только значения необходимые функции.
__>Замечательно. Только тогда постоянно придется напрягаться при редактировании, чтобы не дай бог не ошибиться с этими минимальными наборами значений.
По своему опыту, редактирование выполняется гораздо реже чем чтение, потому оно менее важно. А чтобы пользователи не напрягались, сделайте им IDE, для такого простого ЯП это будет не сложно.
AC>>И у вас получится новый С++,
__>А почему не новая Mathematica?
Не доводилось использовать это ПО.
AC>>ИМХО лучше выбрать что-то одно или подстановку или функции.
__>Кстати, а в чем отличие?
Что-то одно чтобы не перегружать синтаксис. А отличия, думаю только в реализации: функцию вы выполняете рантайм, подстановку компилтайм.
__>Я как-то задумался вот, и получилось, что вроде принципиальной разницы и нет — в Mathematica, например, есть возможность делать запись f[x_]=x^2, которая на первый взгляд кажется определением функции, но на самом деле является заданием щаблона подстановки, говорящего, что всякую текстовую конструкцию вида "f[<something>]" следует заменить на конструкцию "<something>^2".
В вашем варианте подстановки аргументы передаются неявно, что по моему скромному мнению не гуд.

Здравствуйте, AlexCab, Вы писали:

__>>Я имел в виду, что ваш вариант от моего отличается настолько же, насколько синтаксический сахар отличается от конструкции базового языка, которую он подменяет (то есть, является практически только "косметическим" средством).
AC>Не стоит не недооценивать "косметические средства", т.к. это то делает синтаксис визуально красивым и интуитивно понятным.

Да то, как оформить — через "@<ситуация>" или "in case <ситуация>" — второе дело. Первое — определиться с тем, какая конструкция должна быть, и какая ей должна быть присуща семантика.

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

Что такое предметный язык? Имеете в виду Domain-specific language. Так я же его и пытаюсь создать. И эти "a"-шки, и вычисления в контексте — это все для того, чтобы проще было решать специфические задачи — задавать условия контроллеру.

__>>А теперь представьте себе, что эту жуть придется редактировать (а тем более другому человеку).
__>>В вашем же варианте вы определяете не функции, а правила замены "функциональных выражений" наподобие того, что делается в пакете Mathematica, когда пишется, например, f[1] = 1. А это уже, извините, в школе не проходили, и не так просто для объяснения.
AC>В универе проходили, и школе похожие вещи встречались.

Вы ничего не путаете? Запись f(x) = x^2 и запись f(pi) = pi^2 не одно и то же. В первом случае определяется функция, во втором — выражение для расчета значения этой функции на конкретном аргументе pi (числе "пи"). В первом случае дальше по тексту можно написать f(1), а во втором нет.

__>>Например, как воспринимать запись E1(a1) = a2 как "E1(a1) везде по тексту далее заменяется на a2"?
AC>При компиляции сообщать пользователю: "a2 не является числом или параметром функции E1".

__>>Если же настаивать на том, что все "а"-шки, участвующие справа, должны быть указаны в списке "а"-шек слева, то пользователь может задать резонный вопрос — так а зачем тогда вообще этот список ему указывать, если он автоматом определяется по правой части?
AC>Ответ: Это защитит вас от путаницы связанной с не правильным указанием идентификатора и неопределённости его значения, которая может привести к непредсказуемому поведению программы.
Покажите мне на примере, где это от чего защищает.
(И про неопределенность значения — я же указывал, что по умлчанию считается, что все значения берутся из S0).

__>>Во-первых, как там представляются ситуации — векторами или другим образом — не принципиально. На момент написания программы пользователь уже знает, что ситуации заданы, и имеет четкое представление о них. То есть, у него есть вся информация о том, что значит ситуация S0 или S1. Во-вторых, я обозначил значения a1,a2,...,a10 только для удобства. На самом деле эти идентификаторы несут информацию о том, какое значение содержат. Например, "a1" <-> "Pressure", a2 <-> "Temperature" и т.д. Сами же ситуации выглядят наподобие
__>>S1 — ситуация при включенном нагреве теном на мощность 200кВт",
__>>S2 — ситуация при включенном нагреве теном на мощность 400Вт" и т.п.
AC>Если пользователь знает что у него есть "тен на мощности 200кВт", "тен на мощности 400Вт", "Pressure", "Temperature" etc. Зачем тогда вся эта возня с ситуациями, контекстами, подстановками? ИМХО, пусть пользователь пишет как знает: 'включить "тен на мощность 200кВт" если "Temperature" > 100 и "Pressure" будет > 200'.

Замечательно! Предложите конкретный вариант записи
"если текущая температура < 30 и при включении тена на мощность 200кВ будет выполняться Pressure*Volume^{3/4}/Temperature < 100, то включить тен на 200кВ, иначе
если текущая температура < 30 и при включении тена на мощность 100кВ будет выполняться Pressure*Volume^{3/4}/Temperature < 100, то включить тен на 100кВ".

__>>Те же претензии, что и выше
__>>- нужно правильное оформление функций;
AC>Привольно оформленные функции легшие читать.

Ага, особенно те, у которых больше 4-ех параметров...

__>>- увеличивается громоздкость (трудно читать и редактировать).
AC>Чтоб редактировать с начало нужно понять, и "громоздкость" ту как нельзя к стати.

Первый раз слышу, чтобы громозкость облегчала чтение.

AC>>>Передавать придётся не весь контекст а только значения необходимые функции.
__>>Замечательно. Только тогда постоянно придется напрягаться при редактировании, чтобы не дай бог не ошибиться с этими минимальными наборами значений.
AC>По своему опыту, редактирование выполняется гораздо реже чем чтение, потому оно менее важно. А чтобы пользователи не напрягались, сделайте им IDE, для такого простого ЯП это будет не сложно.

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

AC>>>И у вас получится новый С++,
__>>А почему не новая Mathematica?
AC>Не доводилось использовать это ПО.

Ну возьмите любую систму с символьными вычислениями.

AC>>>ИМХО лучше выбрать что-то одно или подстановку или функции.
__>>Кстати, а в чем отличие?
AC>Что-то одно чтобы не перегружать синтаксис. А отличия, думаю только в реализации: функцию вы выполняете рантайм, подстановку компилтайм.
__>>Я как-то задумался вот, и получилось, что вроде принципиальной разницы и нет — в Mathematica, например, есть возможность делать запись f[x_]=x^2, которая на первый взгляд кажется определением функции, но на самом деле является заданием щаблона подстановки, говорящего, что всякую текстовую конструкцию вида "f[<something>]" следует заменить на конструкцию "<something>^2".
AC>В вашем варианте подстановки аргументы передаются неявно, что по моему скромному мнению не гуд.
Вы про какой мой вариант ведете речь?

AC>>Это я о том что такие большие выражения вряд-ли встретятся при программировании контроллеров в рамках одной модели. Но по сравнению с предметным ЯП созданным по модели, это действительно жутко.
__>Что такое предметный язык? Имеете в виду Domain-specific language.
Да именно.
__>Так я же его и пытаюсь создать. И эти "a"-шки, и вычисления в контексте — это все для того, чтобы проще было решать специфические задачи — задавать условия контроллеру.
По моему вы чрезмерно концентрируетесь на вычислениях и контекстах, а стоило бы на предметной области где язык будет применяться и на пользователях которые его будут применять.
AC>>В универе проходили, и школе похожие вещи встречались.
__>Вы ничего не путаете? Запись f(x) = x^2 и запись f(pi) = pi^2 не одно и то же. В первом случае определяется функция, во втором — выражение для расчета значения этой функции на конкретном аргументе pi (числе "пи"). В первом случае дальше по тексту можно написать f(1), а во втором нет.
ИМХО от f(pi) = pi^2 до f(x) = x^2 рукой подать.
AC>>Ответ: Это защитит вас от путаницы связанной с не правильным указанием идентификатора и неопределённости его значения, которая может привести к непредсказуемому поведению программы.
__>Покажите мне на примере, где это от чего защищает.
__>(И про неопределенность значения — я же указывал, что по умлчанию считается, что все значения берутся из S0).

S0: t1->25,t2->52, t3->12   
S1: t1->13,t2->33, t3->21 
S1: t1->00,t2->65, t3->21 
E1: t1+t3                 //Парвельно: E1: t1+t2 (очепятка)
E2: t1 
E3: t1/(t2 *[@S3 E2])     //Работает не всегда(зависимость от другого контекста).
E1 OR E2 OR[@S1 E2]

_AC>>Если пользователь знает что у него есть "тен на мощности 200кВт", "тен на мощности 400Вт", "Pressure", "Temperature" etc. Зачем тогда вся эта возня с ситуациями, контекстами, подстановками? ИМХО, пусть пользователь пишет как знает: 'включить "тен на мощность 200кВт" если "Temperature" > 100 и "Pressure" будет > 200'.
__>Замечательно! Предложите конкретный вариант записи
__>"если текущая температура < 30 и при включении тена на мощность 200кВ будет выполняться Pressure*Volume^{3/4}/Temperature < 100, то включить тен на 200кВ, иначе
__>если текущая температура < 30 и при включении тена на мощность 100кВ будет выполняться Pressure*Volume^{3/4}/Temperature < 100, то включить тен на 100кВ".
Для этого нужна конкретная модель вашего тех. процесса(опишите её), из этой модели уже можно будет построить ЯП.
AC>>Привольно оформленные функции легшие читать.
__>Ага, особенно те, у которых больше 4-ех параметров...
Главное что все они соответствуют шаблону: <имя>(<параметры>) = <выражение>.
__>>>- увеличивается громоздкость (трудно читать и редактировать).
AC>>Чтоб редактировать с начало нужно понять, и "громоздкость" ту как нельзя к стати.
__>Первый раз слышу, чтобы громозкость облегчала чтение.
Не чтение, понимание.
AC>>По своему опыту, редактирование выполняется гораздо реже чем чтение, потому оно менее важно. А чтобы пользователи не напрягались, сделайте им IDE, для такого простого ЯП это будет не сложно.
__>А по моему, практически одинаково, так как к прочтению работающей программы возвращаются лишь для того, чтоб внести в нее изменения.
Когда вы вносите изменения вы больше читаете или пишите?
AC>>В вашем варианте подстановки аргументы передаются неявно, что по моему скромному мнению не гуд.
__>Вы про какой мой вариант ведете речь?

[@S1 2*[@S3 a1 + 2] ] -> [@S1 2*(32+2) ] -> [@S1 2*34 ] -> [@S1 68 ] -> 68

Здравствуйте, _hum_, Вы писали:

__>Вот давайте конкретно, как в вашем варианте представить простенькие:
__>1) если "текущая температура < 30" AND ("давление * объем^(3/2), при поднятии контроллером температуры на 35 градусов" < "давление*объем^(3/2) при поднятии контроллером температуры на 70 градусов", то поднять температуру на 70 градусов;
__>2) если "текущая температура < 30" AND ("давление * объем^(3/2), при поднятии контроллером температуры на 35 градусов" > "давление*объем^(3/2) при поднятии контроллером температуры на 70 градусов", то поднять температуру на 35 градусов;

Присоединюсь к обсуждению. Интересно же.

Вариант 1. Неявный контекст

Выражение вычисляется всегда в "рабочем" контексте, если не указано иное. В начале вычислений рабочий контекст = начальный контекст (т.е. текущее, реальное состояние, не смоделированное). Рабочий контекст можно поменять с помощью ключевого слова ПОСЛЕ. Скорее всего нужно также возвращаться к начальному контексту, чтобы сравнивать смоделированные значения и изначальные. Введем для этого ключевое слово НАСТОЯЩИЙ

== Дословно решение:

ЕСЛИ Температура < 30 И 
    ((Давление * Объем ^ (3/2) ПОСЛЕ температура += 35) < 
    (Давление * Объем ^ (3/2) ПОСЛЕ температура += 70)) 
ТО температура += 70

ЕСЛИ Температура < 30  И 
    ((Давление * Объем ^ (3/2) ПОСЛЕ температура += 35) > 
    (Давление * Объем ^ (3/2) ПОСЛЕ температура += 70)) 
ТО температура += 35

=== После рефакторинга:

ТемператураНизкая = Температура < 30
ЧтоТо = Давление * Объем ^ (3/2)
ЧтоТоПосле($Т) = ЧтоТо ПОСЛЕ температура += $Т

ЕСЛИ ТемператураНизкая И (ЧтоТоПосле(35) < ЧтоТоПосле(70)) ТО температура += 70
ЕСЛИ ТемператураНизкая И (ЧтоТоПосле(35) > ЧтоТоПосле(70)) ТО температура += 35

=== Еще примеры

Вычисление ЧтоТо после повышения температуры на 35:
ЧтоТо ПОСЛЕ температура += 35 

Сравнивается ЧтоТо после повышения температуры на 35 и ЧтоТо после повышения температуры на 55 (35 затем 20):
(ЧтоТо ПОСЛЕ температура += 20) < ЧтоТо ПОСЛЕ температура += 35 

Сравнивается ЧтоТо после повышения на 35 и ЧтоТо начальное (до повышения на 35):
ЧтоТо < (ЧтоТо НАСТОЯЩИЙ) ПОСЛЕ температура += 35

=== И совсем программистское:

ВыбратьИзменениеТемпературыКонтролируя($Параметр, $Т1, $Т2) =
    ПараметрПосле($T) = $Параметр ПОСЛЕ температура += $Т
    ЕСЛИ ТемператураНизкая И (Параметр($Т1) < Параметр($Т2)) ТО температура += $Т1
    ЕСЛИ ТемператураНизкая И (Параметр($Т1) > Параметр($Т2)) ТО температура += $Т2

ВыбратьИзменениеТемпературыКонтролируя(ЧтоТо, 35, 70)

Мне кажется будут проблемы с отладкой такого кода


Вариант 2:

Явно указывается контекст (вернее действия, которые приводят к контексту). Действия надо заранее описать (присвоить им названия). Значения без указания контекста — это текущие (не смоделированные) значения.

ТемператураНизкая = Температура < 30
ЧтоТо = Давление * Объем ^ (3/2)

Д1 = ДЕЛАЙ температура += 35
Д2 = ДЕЛАЙ температура += 70

ЕСЛИ Температура < 30 И (Д1.ЧтоТо < Д2.ЧтоТо) ДЕЛАЙ Д2
ЕСЛИ Температура < 30 И (Д1.ЧтоТо > Д2.ЧтоТо) ДЕЛАЙ Д1

Пример:

ЧтоТо после повышения температуры на 35
Д1.ЧтоТо 

ЧтоТо после повышения температуры на 70
Д2.ЧтоТо 

ЧтоТо после повышения температуры на 35 затем еще на 70
Д1.Д2.ЧтоТо

С отладкой все проще

Итого:

Первый вариант гибче, но сложнее. Второй, соответственно проще.

1. Вопрос в том, насколько часто будут требоваться "вложения" контекстов (типа Д1.Д2.Д3.Д4 или ... ПОСЛЕ ... ПОСЛЕ ... ПОСЛЕ)?
2. Как будет производиться моделирование, если будущее состояние само основано на программе (коде)? Т.е. если мы увеличили мощность тэна, то из модели следует, что температура поднимется до 100 градусов, но в программе (например) заложены правила, не допускающие поднятия температуры даже до 80 (т.е. написанные правила пытаются ее снизить). Поэтому на практике она никогда не будет 100 градусов. Значит расчеты модели не верны, а значит правила основанные этой модели могут не работать или работать не так как ожидалось. Что дальше я даже боюсь представить

Здравствуйте, _hum_, Вы писали:

__>Ваше "ВЫПОЛНИТЬ ЛУЧШЕЕ" похоже на "СДЕЛАТЬ_ВСЕ_ХОРОШО". Суть же в том и состоит, чтобы расписать контроллеру, как именно он должен выбирать то, что пользователь называет "лучшее".
Нет, у него жёсткая семантика — вычисляем <expression> в каждом из перечисленных контекстов и выбираем то действие, которое максимизирует указанный критерий.
Суть состоит вовсе не в том. Вы стараетесь написать язык, требующий от программиста педантичной внимательности, многословный, и провоцирующий ошибки. Зачем?
Я бы понял, если бы вы были скованы каким-то существующим языком. Скажем, писали библиотеку на C. Но у вас руки полностью развязаны, можно сделать язык простым, понятным, выразительным и предотвращающим ошибки.

__>Что здесь понимается под пост-условием? Проверка условия после того,к ак действие выполнено, или проверка условия в предположении, что действие произойдет, но реально оно еще не произошло?
Проверка в предположении, что действие произойдёт. Идея — в том, чтобы не предоставлять возможностей, не имеющих физического смысла. В частности, не имеет смысла выполнять действие А, а проверять условие в предположении выполнения действия Б. Не имеет смысла проверять условие после того, как действие произошло — решение уже было принято.

__>Вот давайте конкретно, как в вашем варианте представить простенькие:
__>1) если "текущая температура < 30" AND ("давление * объем^(3/2), при поднятии контроллером температуры на 35 градусов" < "давление*объем^(3/2) при поднятии контроллером температуры на 70 градусов", то поднять температуру на 70 градусов;
__>2) если "текущая температура < 30" AND ("давление * объем^(3/2), при поднятии контроллером температуры на 35 градусов" > "давление*объем^(3/2) при поднятии контроллером температуры на 70 градусов", то поднять температуру на 35 градусов;

ЕСЛИ "текущая температура < 30" ТО 
  ИЗ "поднять температуру на 35 градусов", "поднять температуру на 70 градусов" 
  ВЫПОЛНИТЬ ЛУЧШЕЕ ПО "давление * объем^(3/2)"

Годится?

Здравствуйте, AlexCab, Вы писали:

AC>>>по сравнению с предметным ЯП созданным по модели, это действительно жутко.
__>>Что такое предметный язык? Имеете в виду Domain-specific language.
AC>Да именно.
__>>Так я же его и пытаюсь создать. И эти "a"-шки, и вычисления в контексте — это все для того, чтобы проще было решать специфические задачи — задавать условия контроллеру.
AC>По моему вы чрезмерно концентрируетесь на вычислениях и контекстах, а стоило бы на предметной области где язык будет применяться и на пользователях которые его будут применять.

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

AC>>>В универе проходили, и школе похожие вещи встречались.
__>>Вы ничего не путаете? Запись f(x) = x^2 и запись f(pi) = pi^2 не одно и то же. В первом случае определяется функция, во втором — выражение для расчета значения этой функции на конкретном аргументе pi (числе "пи"). В первом случае дальше по тексту можно написать f(1), а во втором нет.
AC>ИМХО от f(pi) = pi^2 до f(x) = x^2 рукой подать.

от f(x) к f(pi) — да, но никак не в обратную сторону.

AC>>>Ответ: Это защитит вас от путаницы связанной с не правильным указанием идентификатора и неопределённости его значения, которая может привести к непредсказуемому поведению программы.
__>>Покажите мне на примере, где это от чего защищает.
__>>(И про неопределенность значения — я же указывал, что по умлчанию считается, что все значения берутся из S0).
AC>

AC>S0: t1->25,t2->52, t3->12   
AC>S1: t1->13,t2->33, t3->21 
AC>S1: t1->00,t2->65, t3->21 
AC>E1: t1+t3                 //Парвельно: E1: t1+t2 (очепятка)
AC>E2: t1 
AC>E3: t1/(t2 *[@S3 E2])     //Работает не всегда(зависимость от другого контекста).
AC>E1 OR E2 OR[@S1 E2]
AC>

Насчет опечатки...Следуя вашей логике, тогда следовало бы для защиты от опечатки также вместо

E3: t1/(t2 *[@S3 E2])

писать

E3(t1,t2,S3,E2): t1/(t2 *[@S3 E2])

Не находите это, мягко говоря, недекватным?
Насчет второго с "работает не всегда" не понял, что вы хотели сказать. Если заранее договариваться об аппликативном порядке вычислений (сначала внутренние выражения, а затем внешние, их включающие), то не вижу, когда может возникнуть неоднозначность. Можете более подробно расписать?

_AC>>>Если пользователь знает что у него есть "тен на мощности 200кВт", "тен на мощности 400Вт", "Pressure", "Temperature" etc. Зачем тогда вся эта возня с ситуациями, контекстами, подстановками? ИМХО, пусть пользователь пишет как знает: 'включить "тен на мощность 200кВт" если "Temperature" > 100 и "Pressure" будет > 200'.
__>>Замечательно! Предложите конкретный вариант записи
__>>"если текущая температура < 30 и при включении тена на мощность 200кВ будет выполняться Pressure*Volume^{3/4}/Temperature < 100, то включить тен на 200кВ, иначе
__>>если текущая температура < 30 и при включении тена на мощность 100кВ будет выполняться Pressure*Volume^{3/4}/Temperature < 100, то включить тен на 100кВ".
AC>Для этого нужна конкретная модель вашего тех. процесса(опишите её), из этой модели уже можно будет построить ЯП.

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

AC>>>В вашем варианте подстановки аргументы передаются неявно, что по моему скромному мнению не гуд.
__>>Вы про какой мой вариант ведете речь?
AC>

[@S1 2*[@S3 a1 + 2] ] -> [@S1 2*(32+2) ] -> [@S1 2*34 ] -> [@S1 68 ] -> 68

Да, абсолютная прозрачность — это инкапсулирование все в функцию со строгой передачей всех данных через ее аргументы. Но ведь нужно знать меру — вы же при написании функции расчета длины окружности не будете писать length(radius,pi), а передадите значение числа pi неявно через контекст, потому как считаете, что это не затруднит понимание происходящего, но при этом уменьшит громоздкость. Вот аналогично и я пытаюсь найти компромисс — чтобы и жизнь пользователю облегчить, и понимание происходящего при вычислениях не усложнить.

Здравствуйте, Буравчик, Вы писали:

Б>Здравствуйте, _hum_, Вы писали:

__>>Вот давайте конкретно, как в вашем варианте представить простенькие:
__>>1) если "текущая температура < 30" AND ("давление * объем^(3/2), при поднятии контроллером температуры на 35 градусов" < "давление*объем^(3/2) при поднятии контроллером температуры на 70 градусов", то поднять температуру на 70 градусов;
__>>2) если "текущая температура < 30" AND ("давление * объем^(3/2), при поднятии контроллером температуры на 35 градусов" > "давление*объем^(3/2) при поднятии контроллером температуры на 70 градусов", то поднять температуру на 35 градусов;

Б>Присоединюсь к обсуждению. Интересно же.

Б>Вариант 1. Неявный контекст

Б>Выражение вычисляется всегда в "рабочем" контексте, если не указано иное. В начале вычислений рабочий контекст = начальный контекст (т.е. текущее, реальное состояние, не смоделированное). Рабочий контекст можно поменять с помощью ключевого слова ПОСЛЕ. Скорее всего нужно также возвращаться к начальному контексту, чтобы сравнивать смоделированные значения и изначальные. Введем для этого ключевое слово НАСТОЯЩИЙ

Б>

Б>== Дословно решение:

Б>ЕСЛИ Температура < 30 И 
Б>    ((Давление * Объем ^ (3/2) ПОСЛЕ температура += 35) < 
Б>    (Давление * Объем ^ (3/2) ПОСЛЕ температура += 70)) 
Б>ТО температура += 70

Б>ЕСЛИ Температура < 30  И 
Б>    ((Давление * Объем ^ (3/2) ПОСЛЕ температура += 35) > 
Б>    (Давление * Объем ^ (3/2) ПОСЛЕ температура += 70)) 
Б>ТО температура += 35
Б>

[...]

Б>Мне кажется будут проблемы с отладкой такого кода


Б>Вариант 2:

Б>Явно указывается контекст (вернее действия, которые приводят к контексту). Действия надо заранее описать (присвоить им названия). Значения без указания контекста — это текущие (не смоделированные) значения.

Б>

Б>ТемператураНизкая = Температура < 30
Б>ЧтоТо = Давление * Объем ^ (3/2)

Б>Д1 = ДЕЛАЙ температура += 35
Б>Д2 = ДЕЛАЙ температура += 70

Б>ЕСЛИ Температура < 30 И (Д1.ЧтоТо < Д2.ЧтоТо) ДЕЛАЙ Д2
Б>ЕСЛИ Температура < 30 И (Д1.ЧтоТо > Д2.ЧтоТо) ДЕЛАЙ Д1
Б>

[...]

Б>С отладкой все проще


Б>Итого:

Б>Первый вариант гибче, но сложнее. Второй, соответственно проще.

Да, ваш второй вариант — это по сути то, что и я пытаюсь ввести, и интересуюсь здесь у знающих людей, может быть, они где-то уже видели готовую реализацию, чтобы самому не разбираться в вопросах, как это реализовать без внутренних противоречий с теми же вложенными

типа Д1.Д2.Д3.Д4 или ... ПОСЛЕ ... ПОСЛЕ ... ПОСЛЕ

и проч.


Б>1. Вопрос в том, насколько часто будут требоваться "вложения" контекстов (типа Д1.Д2.Д3.Д4 или ... ПОСЛЕ ... ПОСЛЕ ... ПОСЛЕ)?

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

Б>2. Как будет производиться моделирование, если будущее состояние само основано на программе (коде)? Т.е. если мы увеличили мощность тэна, то из модели следует, что температура поднимется до 100 градусов, но в программе (например) заложены правила, не допускающие поднятия температуры даже до 80 (т.е. написанные правила пытаются ее снизить). Поэтому на практике она никогда не будет 100 градусов. Значит расчеты модели не верны, а значит правила основанные этой модели могут не работать или работать не так как ожидалось. Что дальше я даже боюсь представить

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, _hum_, Вы писали:

__>>Вот давайте конкретно, как в вашем варианте представить простенькие:
__>>1) если "текущая температура < 30" AND ("давление * объем^(3/2), при поднятии контроллером температуры на 35 градусов" < "давление*объем^(3/2) при поднятии контроллером температуры на 70 градусов", то поднять температуру на 70 градусов;
__>>2) если "текущая температура < 30" AND ("давление * объем^(3/2), при поднятии контроллером температуры на 35 градусов" > "давление*объем^(3/2) при поднятии контроллером температуры на 70 градусов", то поднять температуру на 35 градусов;
S>

S>ЕСЛИ "текущая температура < 30" ТО 
S>  ИЗ "поднять температуру на 35 градусов", "поднять температуру на 70 градусов" 
S>  ВЫПОЛНИТЬ ЛУЧШЕЕ ПО "давление * объем^(3/2)"
S>

S>Годится?

Нет! Опишите конкретную семантику конструкции

ИЗ <action 1>, <action2> ВЫПОЛНИТЬ ЛУЧШЕЕ по <expression>

Еще раз подчеркиваю, что контроллер не знает, что такое "лучшее" (это может быть минимум, максимум, минимум квадрата величины, максимум синуса величины и куча всего остального) — ему, грубо говоря, до лампочки. Он ожидает просто инструкций от пользователя, что он должен вычислить и с чем сравнить.

Здравствуйте, _hum_, Вы писали:

__>Здравствуйте, Sinclair, Вы писали:

S>>Здравствуйте, _hum_, Вы писали:

__>>>Вот давайте конкретно, как в вашем варианте представить простенькие:
__>>>1) если "текущая температура < 30" AND ("давление * объем^(3/2), при поднятии контроллером температуры на 35 градусов" < "давление*объем^(3/2) при поднятии контроллером температуры на 70 градусов", то поднять температуру на 70 градусов;
__>>>2) если "текущая температура < 30" AND ("давление * объем^(3/2), при поднятии контроллером температуры на 35 градусов" > "давление*объем^(3/2) при поднятии контроллером температуры на 70 градусов", то поднять температуру на 35 градусов;
S>>

S>>ЕСЛИ "текущая температура < 30" ТО 
S>>  ИЗ "поднять температуру на 35 градусов", "поднять температуру на 70 градусов" 
S>>  ВЫПОЛНИТЬ ЛУЧШЕЕ ПО "давление * объем^(3/2)"
S>>

S>>Годится?

__>Нет! Опишите конкретную семантику конструкции
__>

__>ИЗ <action 1>, <action2> ВЫПОЛНИТЬ ЛУЧШЕЕ по <expression>
__>

Почему нет? Семантика вот такая:
1. Для каждого из <actionX> вычислить <expression>, получив ExpressionValueAfterActionX.
2. Найти максимальное из значений ExpressionValueAfterActionX — MaximumExpressionValue
3. Из тех действий, которые достигают MaximumExpressionValue, выбрать первое по порядку задания. Выполнить его.
В результате семантика — строго такая, как в вашем примере — за минусом ошибки. Ваша программа вообще ничего не будет делать, если давление*объем^(3/2) окажется одинаковым при подъёме температуры что на 35, что на 70 градусов. Моя — выполнит действие.

__>Еще раз подчеркиваю, что контроллер не знает, что такое "лучшее"
Ну так научите его! Вы же разрабатываете язык — вам и карты в руки.
__>(это может быть минимум, максимум, минимум квадрата величины, максимум синуса величины и куча всего остального) — ему, грубо говоря, до лампочки. Он ожидает просто инструкций от пользователя, что он должен вычислить и с чем сравнить.
Зачем все эти сложности? Если пользователь хочет максимизировать синус величины — пусть пишет ВЫПОЛНИТЬ ЛУЧШЕЕ ПО "sin(P * V^(3/2))". Минимизировать квадрат — пусть пишет ЛУЧШЕЕ ПО "-(P * V^(3/2))^2". Какие ещё инструкции нужны?

Если вы боитесь, что программисту будет непонятно, какое значение считается лучшим, то синтаксис легко починить, устранив неопределённость:

ИЗ <actionlist> ВЫПОЛНИТЬ МАКСИМИЗИРУЮЩЕЕ <expression>
ИЗ <actionlist> ВЫПОЛНИТЬ МИНИМИЗИРУЮЩЕЕ <expression>

AC>>По моему вы чрезмерно концентрируетесь на вычислениях и контекстах, а стоило бы на предметной области где язык будет применяться и на пользователях которые его будут применять.
__>Да я ж уже несколько раз предметную область и проблему описал: есть физический процесс,
Какой ф. процесс? Он будет не один? Сколько и каких будет?
__>есть контроллер,
Какой контроллер? МК? ПЛК?
__>способный выполнять конечное число заранее фиксированных воздействий на него,
Каких именно действий? Они заранее определены или пользователь ЯП должен сделать это сам?
__>есть датчики параметров процесса,
Какие датчики каких конкретно параметров?
__>есть модель, способная давать прогнозные показатели параметров процесса при любом из воздействии контроллера.
Какие конкретные параметры для каких конкретных воздействий она может предсказывать?
__>Требуется создать декларативный язык, способный задавать работу контроллера с тем, чтобы регулировать его протекание (ака предотвращать выход параметров за критические значения, поддерживать оптимальный по некоторой заданной пользователем критериальной зависящей от этих параметров функции режим протекания процесса).
Какие из параметров и действий вы хотите включить в ЯП?
__>Насчет опечатки...Следуя вашей логике, тогда следовало бы для защиты от опечатки также вместо
__>

__>E3: t1/(t2 *[@S3 E2])
__>

__> писать
__>

__>E3(t1,t2,S3,E2): t1/(t2 *[@S3 E2])
__>

__>Не находите это, мягко говоря, недекватным?
Наверно всё-таки так:

E3(t1,t2,S3,E2): t1/(t2 * E2(S3))

__>Насчет второго с "работает не всегда" не понял, что вы хотели сказать. Если заранее договариваться об аппликативном порядке вычислений (сначала внутренние выражения, а затем внешние, их включающие), то не вижу, когда может возникнуть неоднозначность. Можете более подробно расписать?
Иногда будет возникать ошибка деление и будет трудно найти откуда этот ноль взялся(потому что он в другом контексте, в месте вызова не упоминаемом).
AC>>Для этого нужна конкретная модель вашего тех. процесса(опишите её), из этой модели уже можно будет построить ЯП.
__>Зачем вам конкретная модель???
Затем что ЯП для программирования контроллеров управляющих чайниками, будет очень сильно отличатся от ЯП для контроллеров управляющих атомными подводными лодками.
__>Ну, раз так хотите, возьмите, например, такую — газ в подогреваемом электротеном вертикальном металлическом цилиндре с поршнем, на который положен некоторый груз.
Вы, помницо писали

Автор: _hum_
Дата: 09.01.13

что у вас один тех. процесс? Потому что ЯП для описания одного тех. процесса, не то-же что для описания нескольких.
__>Да, абсолютная прозрачность — это инкапсулирование все в функцию со строгой передачей всех данных через ее аргументы. Но ведь нужно знать меру — вы же при написании функции расчета длины окружности не будете писать length(radius,pi), а передадите значение числа pi неявно через контекст, потому как считаете, что это не затруднит понимание происходящего, но при этом уменьшит громоздкость. Вот аналогично и я пытаюсь найти компромисс — чтобы и жизнь пользователю облегчить, и понимание происходящего при вычислениях не усложнить.
Pi — константа, потому может быть и глобальной.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, _hum_, Вы писали:

__>>Здравствуйте, Sinclair, Вы писали:

S>>>Здравствуйте, _hum_, Вы писали:


__>>Опишите конкретную семантику конструкции
__>>

__>>ИЗ <action 1>, <action2> ВЫПОЛНИТЬ ЛУЧШЕЕ по <expression>
__>>

S>Семантика вот такая:
S>1. Для каждого из <actionX> вычислить <expression>, получив ExpressionValueAfterActionX.
S>2. Найти максимальное из значений ExpressionValueAfterActionX — MaximumExpressionValue
S>3. Из тех действий, которые достигают MaximumExpressionValue, выбрать первое по порядку задания. Выполнить его.

Ок. Теперь более-менее понятно, о чем вы ведете речь.

S>В результате семантика — строго такая, как в вашем примере — за минусом ошибки. Ваша программа вообще ничего не будет делать, если давление*объем^(3/2) окажется одинаковым при подъёме температуры что на 35, что на 70 градусов. Моя — выполнит действие.

Смотря как посмотреть Может, пользователю так и надо — если значения одинаковы, то не надо ничего делать (или, например, надо начать проверять дополнительные условия). В вашем же случае всегда должно будет исполниться какое-то действие, что не есть гуд

__>>Еще раз подчеркиваю, что контроллер не знает, что такое "лучшее"
S>Ну так научите его! Вы же разрабатываете язык — вам и карты в руки.
__>>(это может быть минимум, максимум, минимум квадрата величины, максимум синуса величины и куча всего остального) — ему, грубо говоря, до лампочки. Он ожидает просто инструкций от пользователя, что он должен вычислить и с чем сравнить.
S>Зачем все эти сложности? Если пользователь хочет максимизировать синус величины — пусть пишет ВЫПОЛНИТЬ ЛУЧШЕЕ ПО "sin(P * V^(3/2))". Минимизировать квадрат — пусть пишет ЛУЧШЕЕ ПО "-(P * V^(3/2))^2". Какие ещё инструкции нужны?

S>Если вы боитесь, что программисту будет непонятно, какое значение считается лучшим, то синтаксис легко починить, устранив неопределённость:
S>

S>ИЗ <actionlist> ВЫПОЛНИТЬ МАКСИМИЗИРУЮЩЕЕ <expression>
S>ИЗ <actionlist> ВЫПОЛНИТЬ МИНИМИЗИРУЮЩЕЕ <expression>
S>

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

"проверить условие 1-> проверить условие 2 -> условие n -> активировать действие"

а

"выбрать из списка {действие1, действие2,...,действиеN} действие, удовлетворяющее условию такому-то"

В моем случае легко строить (понятно любому человеку) разветвления, наподобие

действие 1 = снижение мощности тена до минимальной
действие 2 = отключение тена и подача охладителя
действие 3 = включение аварийной защиты

если "температура > 100", то 
   если  "температура при действии 1 < 100", то действие 1, иначе
      если  "температура < 1000" OR "давление*объем при действии 2 < 300", то действие 2, иначе действие 3.

В вашем же подходе как-то сразу сложно сообразить, что делать в подобном случае...

Здравствуйте, AlexCab, Вы писали:


AC>Какой ф. процесс? Он будет не один? Сколько и каких будет?

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

AC>Какой контроллер? МК? ПЛК?

МК

AC>Каких именно действий? Они заранее определены или пользователь ЯП должен сделать это сам?

Каждое пользовательское действие — это определяемая пользователем комбинация элементарных воздействий, которые могут быть выполнены контролером (включение тена на 0, 100, 200, 300 кВт, включение/выключение охлаждения, установка дополнительной нагрузки на поршень массой 0, 100, 1000 кг). Как именно описывается определение — мне не существенно. Главное, после определения каждое пользовательское действие имеет идентификатор, по которому его в дальнейшем можно легко идентифицировать и на него ссылаться.

AC>Какие датчики каких конкретно параметров?

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

AC>Какие конкретные параметры для каких конкретных воздействий она может предсказывать?

Давление, температуру, объем, концентрацию для любой комбинации элементарных воздействий, указанных ранее.

AC>Какие из параметров и действий вы хотите включить в ЯП?

Все описанные выше.


__>>Насчет опечатки...Следуя вашей логике, тогда следовало бы для защиты от опечатки также вместо
__>>

__>>E3: t1/(t2 *[@S3 E2])
__>>

__>> писать
__>>

__>>E3(t1,t2,S3,E2): t1/(t2 *[@S3 E2])
__>>

__>>Не находите это, мягко говоря, недекватным?
AC>Наверно всё-таки так:
AC>

AC>E3(t1,t2,S3,E2): t1/(t2 * E2(S3))
AC>

Да. Только повторяю вопрос:

Не находите это, мягко говоря, недекватным?

.

__>>Насчет второго с "работает не всегда" не понял, что вы хотели сказать. Если заранее договариваться об аппликативном порядке вычислений (сначала внутренние выражения, а затем внешние, их включающие), то не вижу, когда может возникнуть неоднозначность. Можете более подробно расписать?
AC>Иногда будет возникать ошибка деление и будет трудно найти откуда этот ноль взялся(потому что он в другом контексте, в месте вызова не упоминаемом).

"Трудно найти" и "Работает не всегда(зависимость от другого контекста)" — не кажется вам, что это все же существенно разные понятия.

AC>>>Для этого нужна конкретная модель вашего тех. процесса(опишите её), из этой модели уже можно будет построить ЯП.
__>>Зачем вам конкретная модель???
AC>Затем что ЯП для программирования контроллеров управляющих чайниками, будет очень сильно отличатся от ЯП для контроллеров управляющих атомными подводными лодками.

То есть, если у меня подводная лодка, то чтобы получить от вас совет, я должен выложить здесь всю тех. документацию? Не кажется вам, что это занадто.

__>>Ну, раз так хотите, возьмите, например, такую — газ в подогреваемом электротеном вертикальном металлическом цилиндре с поршнем, на который положен некоторый груз.
AC>Вы, помницо писали

Автор: _hum_
Дата: 09.01.13

что у вас один тех. процесс? Потому что ЯП для описания одного тех. процесса, не то-же что для описания нескольких.

А что изменилось? Цилиндр с газом — это одна модель. Где вы увидели что-то противоречащее этому?

__>>Да, абсолютная прозрачность — это инкапсулирование все в функцию со строгой передачей всех данных через ее аргументы. Но ведь нужно знать меру — вы же при написании функции расчета длины окружности не будете писать length(radius,pi), а передадите значение числа pi неявно через контекст, потому как считаете, что это не затруднит понимание происходящего, но при этом уменьшит громоздкость. Вот аналогично и я пытаюсь найти компромисс — чтобы и жизнь пользователю облегчить, и понимание происходящего при вычислениях не усложнить.
AC>Pi — константа, потому может быть и глобальной.

Контекст тоже состоит из констант.

__>Пусть будет газ в подогреваемом электротеном и и охладждаемым охладителем вертикальном металлическом цилиндре с поршнем, на который положен некоторый груз. Очевидно, процесс один изменение состояния газа.
__>МК
__>Каждое пользовательское действие — это определяемая пользователем комбинация элементарных воздействий, которые могут быть выполнены контролером (включение тена на 0, 100, 200, 300 кВт, включение/выключение охлаждения, установка дополнительной нагрузки на поршень массой 0, 100, 1000 кг). Как именно описывается определение — мне не существенно. Главное, после определения каждое пользовательское действие имеет идентификатор, по которому его в дальнейшем можно легко идентифицировать и на него ссылаться.
__>Датчики давления, температуры, объема, концентрации, силы тяжести со стороны груза.
__>Давление, температуру, объем, концентрацию для любой комбинации элементарных воздействий, указанных ранее.
__>Все описанные выше.
И так у пользователя есть параметры, которые либо такие как есть сейчас, либо такие как будут после некоторого действия. Думаю пользователь при написании ПО будет размышлять, примерно в таком формате: "чтобы поднять давление до 100 нужно увеличить температуру [включить тен] но только если, температура не превысит 200[когда давление достигнет 100]".
Примерно так это должно выглядеть и в коде:

включить тен ЕСЛИ давление > 100 И температура БУДЕТ > 200

и т.д.
И не нужны ни какие передачи контекстов, в любом месте программы у вас один и тот же контекст, хоть и отличающийся в зависимости от времени(т.е. тот который есть сейчас или тот который будет после выполнения действия).
AC>>Наверно всё-таки так:
AC>>

AC>>E3(t1,t2,S3,E2): t1/(t2 * E2(S3))
AC>>

__>Да. Только повторяю вопрос:
__>

__>Не находите это, мягко говоря, недекватным?

.
Нет. Почему вы считаете это неадекватным?
__>"Трудно найти" и "Работает не всегда(зависимость от другого контекста)" — не кажется вам, что это все же существенно разные понятия.
"Трудно найти" это следствие "зависимость от другого контекста", а "Работает не всегда" это причина для "Трудно найти". Не стал расписывать, подумал поймёте. Спрашиваете если что-то не понятно.
AC>>Затем что ЯП для программирования контроллеров управляющих чайниками, будет очень сильно отличатся от ЯП для контроллеров управляющих атомными подводными лодками.
__>То есть, если у меня подводная лодка, то чтобы получить от вас совет, я должен выложить здесь всю тех. документацию? Не кажется вам, что это занадто.
Админы на этом форуме ленивые, скрипт для телепатии так и не запилили, так что если вы хотите получить полезный и конкретный совет, то лучше выложить.
__>А что изменилось? Цилиндр с газом — это одна модель. Где вы увидели что-то противоречащее этому?
Т.е. ЯП будет использоватся исключительно для программирования контроллеров управляющих цилиндрами с газом?
AC>>Pi — константа, потому может быть и глобальной.
__>Контекст тоже состоит из констант.
Значения параметров то изменяются. О если он действительно из констант, возможно лучше просто сделать его глобальным в пределах программы?

Здравствуйте, AlexCab, Вы писали:

__>>Пусть будет газ в подогреваемом электротеном и и охладждаемым охладителем вертикальном металлическом цилиндре с поршнем, на который положен некоторый груз. Очевидно, процесс один изменение состояния газа.
__>>МК
__>>Каждое пользовательское действие — это определяемая пользователем комбинация элементарных воздействий, которые могут быть выполнены контролером (включение тена на 0, 100, 200, 300 кВт, включение/выключение охлаждения, установка дополнительной нагрузки на поршень массой 0, 100, 1000 кг). Как именно описывается определение — мне не существенно. Главное, после определения каждое пользовательское действие имеет идентификатор, по которому его в дальнейшем можно легко идентифицировать и на него ссылаться.
__>>Датчики давления, температуры, объема, концентрации, силы тяжести со стороны груза.
__>>Давление, температуру, объем, концентрацию для любой комбинации элементарных воздействий, указанных ранее.
__>>Все описанные выше.
AC>И так у пользователя есть параметры, которые либо такие как есть сейчас, либо такие как будут после некоторого действия. Думаю пользователь при написании ПО будет размышлять, примерно в таком формате: "чтобы поднять давление до 100 нужно увеличить температуру [включить тен] но только если, температура не превысит 200[когда давление достигнет 100]".
AC>Примерно так это должно выглядеть и в коде:
AC>

AC>включить тен ЕСЛИ давление > 100 И температура БУДЕТ > 200 
AC>

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

"Наша песня хороша, начинай сначала"

Напишите, пожалуйста, наконец, "без передач контекстов", как будет в вашем варианте выглядеть программа:

1) если "текущая температура < 30" AND ("давление * объем^(3/2), при включении тена на 100кВт" < "давление*объем^(3/2) при включении тена на 300кВт"), то включить тен на 300кВт;
2) если "текущая температура < 30" AND ("давление * объем^(3/2), при включении тена на 100кВт" > "давление*объем^(3/2) при включении тена на 300кВт"), то включить тен на 100кВт;

AC>>>Наверно всё-таки так:
AC>>>

AC>>>E3(t1,t2,S3,E2): t1/(t2 * E2(S3))
AC>>>

__>>Да. Только повторяю вопрос:
__>>

__>>Не находите это, мягко говоря, недекватным?

.
AC>Нет. Почему вы считаете это неадекватным?

Знаете, если я покажу такой язык пользователю, он пошлет меня куда подальше, и правильно сделает, ибо для элементарных вещей я буду заставлять его писать уйму кода. Если вы этого не понимаете, то, видимо, дальше не имеет смысла продолжать разговор.

__>>"Трудно найти" и "Работает не всегда(зависимость от другого контекста)" — не кажется вам, что это все же существенно разные понятия.
AC>"Трудно найти" это следствие "зависимость от другого контекста", а "Работает не всегда" это причина для "Трудно найти". Не стал расписывать, подумал поймёте. Спрашиваете если что-то не понятно.

"Работает не всегда" это причина для "Трудно найти"

— вы это серьезно? Тогда это еще один аргумент для сворачивания диалога с вами — у нас слишком разные представления о вещах.

AC>>>Затем что ЯП для программирования контроллеров управляющих чайниками, будет очень сильно отличатся от ЯП для контроллеров управляющих атомными подводными лодками.
__>>То есть, если у меня подводная лодка, то чтобы получить от вас совет, я должен выложить здесь всю тех. документацию? Не кажется вам, что это занадто.
AC>Админы на этом форуме ленивые, скрипт для телепатии так и не запилили, так что если вы хотите получить полезный и конкретный совет, то лучше выложить.

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

__>Ладно, я понял, вы не можете по простейшим примерам понять, в чем проблема. Потому, спасибо за участие в обсуждении, но, думаю, продолжать его с вами в дальнейшем воздержусь, ибо, извините, но "игра не стоит свеч".
Чем могём

Здравствуйте, _hum_, Вы писали:

__>Да, ваш второй вариант — это по сути то, что и я пытаюсь ввести, и интересуюсь здесь у знающих людей, может быть, они где-то уже видели готовую реализацию, чтобы самому не разбираться в вопросах, как это реализовать без внутренних противоречий с теми же вложенными

типа Д1.Д2.Д3.Д4 или ... ПОСЛЕ ... ПОСЛЕ ... ПОСЛЕ

и проч.

1. Контекст модели — это состояние модели в некоторый момент времени. Контекст полностью описывается списоком значений датчиков на этот момент (назовем их свойством контекста). Пользователь может определять свои свойства контекста (вычисляемые значения на основе формул, например ЧтоТо).
2. В формулах не допускается указывать другие контексты, т.е. формулы вычисляются в рамках одного контекста и никак не связаны с другими контекстами.
3. Связь между контекстами указывать можно, но только в выражениях ЕСЛИ .. ДЕЛАЙ .. (например ЕСЛИ Д1.Д2.Д3.ЧтоТо < Д1.ЧтоТо). При этом контекст всегда указывается начиная от текущего (реального) состояния системы.

Т.е. ограничения п.2 и п.3 сильно упростят понимание программы и ее реализацию. Но вот насколько сильно эти ограничения затруднят работу пользователя?

Реализация простая:
— определить все контексты, которые интересны пользователю (Например, Д1 и Д1.Д2.Д3 и Д2)
— смоделировать эти контексты (вычислить свойства — показания датчиков)
— вычислить значения пользовательских свойств (на основе формул) для всех контекстов
— выполнить программу ЕСЛИ ... ТО

Здравствуйте, _hum_, Вы писали:

__>Здравствуйте, Sinclair, Вы писали:

__>Смотря как посмотреть Может, пользователю так и надо — если значения одинаковы, то не надо ничего делать (или, например, надо начать проверять дополнительные условия). В вашем же случае всегда должно будет исполниться какое-то действие, что не есть гуд
Мне кажется, вы хитрите. Физического смысла в том, чтобы не выполнять никакое действие из сравниваемых нет. То, что в моём случае всегда будет исполнено какое-то действие — однозначно есть гуд. Просто потому, что это сразу очевидно при чтении программы. В вашей программе то, что иногда может не выполняться никакое действие совершенно неочевидно. Просто потому, что в этой простыне, в которой каждое выражение повторяется минимум дважды, отличие "всегда выполнять" от "иногда не выполнять" кроется в единственном символе.
Вы понимаете, что раскладываете грабли в вопросе, где пользователи хотят абсолютную надёжность?

__>Да, если и делать, то только как последний вариант, потому как общие понятия "оптимальности" могут сильно разниться. Но ваш вариант мне не нравится тем, что в нем упор делается на действиях, а не на условиях. То есть, не
__>

__>"проверить условие 1-> проверить условие 2 -> условие n -> активировать действие"
__>

__>а

__>

__>"выбрать из списка {действие1, действие2,...,действиеN} действие, удовлетворяющее условию такому-то"
__>

Я делаю это сознательно.

__>В моем случае легко строить (понятно любому человеку) разветвления, наподобие

__>

__>действие 1 = снижение мощности тена до минимальной
__>действие 2 = отключение тена и подача охладителя
__>действие 3 = включение аварийной защиты

__>если "температура > 100", то 
__>   если  "температура при действии 1 < 100", то действие 1, иначе
__>      если  "температура < 1000" OR "давление*объем при действии 2 < 300", то действие 2, иначе действие 3.

__>

__>В вашем же подходе как-то сразу сложно сообразить, что делать в подобном случае...
Кто-то из нас исходит из неверных предположений. Вам кажется, что вы нашли способ описать решение задачи — при помощи внесения мозгосоворачивающей концепции "результат выражения при условии что". Да, это очень мощная пушка, но, к сожалению, 75% её мощности уходят на то, чтобы позволять писать неверные программы.
Отвлекитесь от идеи "вычислять произвольное выражение в произвольном контексте" — она имеет исключительно академический интерес. Рассмотрите решения с точки зрения прикладного программиста.

Программы на "моём" языке легко читать и они понятны. Программы на вашем языке читать труднее, чем финансовое законодательство. И самое плохое — то, что на вашем языке неверные программы визуально не отличаются от верных. Вы усердно закладываете способы делать случайные ошибки, и способы комбинировать эти способы.
Моя идея — ровно противоположна вашей. Вы хотите дать программисту возможность в любом месте поставить "вычисли это в контексте X", а я хочу не дать программисту указывать контекст руками. Ровно потому, что это удваивает шансы сделать ошибку, а мы хотим облегчить написание корректных программ.

Давайте вернёмся к истокам: зачем прикладному программисту вычислять выражение в некотором контексте?
Пока что вы привели 2 сценария:
1. Проверить, не приведёт ли действие к выходу контролируемого параметра за определённый диапазон и не дать выполнить это действие.
2. Выбрать из N действий то, которое приводит к максимальному (минимальному) значению контролируемого параметра.

Постарайтесь подумать о том, в каких ещё случаях вам может потребоваться вычислять значение "в контексте".
Я не случайно попросил вас привести как можно больше примеров как можно более реальных программ. Когда вы спорите со мной, у вас появляется искушение приводить экстремальные крайние случаи, вместо анализа необходимости таких случаев.
И вообще, помните о том, что язык должен позволять выражать намерение, а не несущественные подробности по его достижению.

Теперь давайте вернёмся к вашей программе:

если "температура > 100", то 
  если  "температура при действии 1 < 100", то действие 1, иначе
    если  "температура < 1000" OR "давление*объем при действии 2 < 300", то действие 2, иначе действие 3.

Вам очевидны намерения программиста, который её писал? Мне — нет.
Есть подозрение, что тут смешаны две разных задачи:
1. Управление процессом (в предположительно нормальных условиях)
2. Предотвращение аварийных ситуаций.
Меня пугает изобилие условий перед тем, как выполнить действие 3. Малейшая ошибка — и аварийная защита так и не включится!
Совершенно непонятно, имел ли в виду программист "включать аварийную защиту всегда при превышении температурой 1000 и давлением 300" (а может быть там не и, а или — просто программист неверно в уме инвертировал логическую формулу ((T > 1000) or (P*V > 300))), или имел в виду "держать температуру в пределах 100, если получается, или хотя бы 1000, если не получается".
Что, если давление * объём при действии 1 будет 600, при температуре 80? Нас это всё ещё устроит, или всё-таки нужно контролировать этот параметр при всех действиях?
Непонятно, можно ли делать несколько действий одновременно (и нужно ли)?

Если же считать, что программа полностью корректна, то в "моём" варианте языка она запишется вот так:

ЕСЛИ T > 100 ТО CнизитьМощностьТэна ЕСЛИТОГДА T < 100
ИНАЧЕ 
  ЕСЛИ T < 1000 ОтключитьТэнИПодатьОхладитель
  ИНАЧЕ
    ОтключитьТэнИПодатьОхладитель ЕСЛИТОГДА P*V < 300
      ИНАЧЕ ВключитьАварийнуюЗащиту

На всякий случай, синтаксис и семантика оператора "ЕСЛИ ... ТО ... ЕСЛИТОГДА ... ИНАЧЕ ..." такая:

[ЕСЛИ <predicatePre> ТО] <action> [EСЛИТОГДА <predicatePost>] [ИНАЧЕ <actionClause>]

Три из четырёх блоков — опциональные:
1. Блок "ЕСЛИ ... ТО" при его наличии определяет предикат, вычисляемый над текущим состоянием модели. Если он вычисляется в true, то продолжаем анализ. Если нет — то двигаемся в блок "ИНАЧЕ" (если он есть).
2. Блок <action> определяет одновременно действие для выбора, а также контекст для вычисления блока "ЕСЛИТОГДА" (если он есть)
3. Блок ЕСЛИТОГДА определяет предикат для вычисления в предположении, что указанное действие произведено. Если он вычисляется в true, то можно выбирать действие, указанное в <action>.
4. Если хотя бы один из predicatePre или predicatePost не вычислился в True, то мы выполняем ветку ИНАЧЕ. В ней может быть любой из операторов выбора действия — как оператор "ЕСЛИ ... ТО ... ЕСЛИТОГДА ... ИНАЧЕ ...", так и оператор "ИЗ ... ВЫПОЛНИТЬ МАКСИМИЗИРУЮЩЕЕ/МИНИМИЗИРУЮЩЕЕ".

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

Здравствуйте, _hum_, Вы писали:

AC>>Примерно так это должно выглядеть и в коде:
AC>>

AC>>включить тен ЕСЛИ давление > 100 И температура БУДЕТ > 200 
AC>>

AC>>и т.д.
__>Напишите, пожалуйста, наконец, "без передач контекстов", как будет в вашем варианте выглядеть программа:

__>

__>1) если "текущая температура < 30" AND ("давление * объем^(3/2), при включении тена на 100кВт" < "давление*объем^(3/2) при включении тена на 300кВт"), то включить тен на 300кВт;
__>2) если "текущая температура < 30" AND ("давление * объем^(3/2), при включении тена на 100кВт" > "давление*объем^(3/2) при включении тена на 300кВт"), то включить тен на 100кВт; 
__>

Обратите внимание на то, что AlexCab теперь идёт по тому же пути, что я предложил — неявное указание контекста при помощи указания действия для выполнения.

Это происходит оттого, что мы с ним интуитивно чувствуем, что произвольные комбинации выражений-в-контекстах не нужны и даже вредны. Ну, то есть вашим пользователям никогда в жизни не потребуется вычислять "(давление при выключении тэна 1) умножить на (температуру при включении тэна 2)".
Значит, любой синтаксис, который позволяет писать такие выражения, должен быть запрещён как провоцирующий ошибки.
Вы привели пока что только 1 сценарий, в котором может потребоваться смешивать контексты — сравнение значений. Ключевой особенностью этого сценария является то, что одним и тем же является вычисляемое выражение.
То есть, опять же, вашим пользователям не потребуется сравнивать "(давление при выключении тэна 1) > (температура при включении тэна 2)".
Именно в эту сторону нужно копать для построения удобного, понятного, и надёжного языка.

Здравствуйте, Sinclair, Вы писали:
S>Обратите внимание на то, что AlexCab теперь идёт по тому же пути, что я предложил — неявное указание контекста при помощи указания действия для выполнения.
Но думаю ТСу нужна именно неявная передача контекста в функцию, а не ЯП для программирования контроллеров