Re[25]: Декларативность и зависимость вычисления выражения от контекста - Философия программирования

Стоит задача создания специализированного языка для задания программы действий некоторому устройству по схеме: фиксируемая ситуация -> действие на нее. При этом ставятся ограничения, чтобы язык был достаточно простым для обучения и экспрессивным (программы на нем просты и читабельны). Выбрал декларативный подход (без использования понятия именованных изменяемых ячеек памяти) с реализацией просто по схеме: задается логическое условие на ситуацию и после него прописывается действие. Но столкнулся со следующей трудностью. Мне нужно, чтобы в этом языке можно было легко задавать следующее условие: "для определения ситуации вычисли данное выражение E в контексте С1, затем в контексте C2 и сравни результат". Вопрос, как в декларативном программировании проще и естественнее ввести понятие контекста (будет ли это тогда вообще декларативным программированием?). Какие подводные камни здесь могут быть (по аналогии с подводными камнями в виде побочных эффектов в нечистых функциональных языках программирования). Может быть, есть какой-то известный язык, где подобное реализовано?

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

__>Стоит задача создания специализированного языка для задания программы действий некоторому устройству по схеме: фиксируемая ситуация -> действие на нее. При этом ставятся ограничения, чтобы язык был достаточно простым для обучения и экспрессивным (программы на нем просты и читабельны). Выбрал декларативный подход (без использования понятия именованных изменяемых ячеек памяти) с реализацией просто по схеме: задается логическое условие на ситуацию и после него прописывается действие. Но столкнулся со следующей трудностью. Мне нужно, чтобы в этом языке можно было легко задавать следующее условие: "для определения ситуации вычисли данное выражение E в контексте С1, затем в контексте C2 и сравни результат". Вопрос, как в декларативном программировании проще и естественнее ввести понятие контекста (будет ли это тогда вообще декларативным программированием?). Какие подводные камни здесь могут быть (по аналогии с подводными камнями в виде побочных эффектов в нечистых функциональных языках программирования). Может быть, есть какой-то известный язык, где подобное реализовано?

Если явная передача контекста в каждое вычисление слишком замусоривает код, то можно посмотреть в сторону монады Reader (Хаскелл). С помощью нее легко описать вычисление, допускающее чтение значений из заданного окружения (контекста).

type User = String
type Password = String
type UsersTable = [(User,Password)]

-- контекстом служит таблица
pwds :: UsersTable
pwds = [("Bill","123"),("Ann","qwerty"),("John","2sRq8P")]

-- возвращает длину пароля пользователя  или -1, если такого пользователя нет
getPwdLen :: User -> Reader UsersTable Int
getPwdLen person = do
  mbPwd <- asks $ lookup person 
  let mbLen = fmap length mbPwd
  let len = fromMaybe (-1) mbLen
  return len

Используем

> runReader (getPwdLen "Ann") pwds
6
> runReader (getPwdLen "Ann") []
-1

Здравствуйте, _hum_, Вы писали:
__>Стоит задача создания специализированного языка для задания программы действий некоторому устройству по схеме: фиксируемая ситуация -> действие на нее. При этом ставятся ограничения, чтобы язык был достаточно простым для обучения и экспрессивным (программы на нем просты и читабельны). Выбрал декларативный подход (без использования понятия именованных изменяемых ячеек памяти)
ИМХО, "без использования понятия именованных изменяемых ячеек памяти" это не про декларативный подход, это про функциональный.
__>с реализацией просто по схеме: задается логическое условие на ситуацию и после него прописывается действие. Но столкнулся со следующей трудностью. Мне нужно, чтобы в этом языке можно было легко задавать следующее условие: "для определения ситуации вычисли данное выражение E в контексте С1, затем в контексте C2 и сравни результат". Вопрос, как в декларативном программировании проще и естественнее ввести понятие контекста (будет ли это тогда вообще декларативным программированием?). Какие подводные камни здесь могут быть (по аналогии с подводными камнями в виде побочных эффектов в нечистых функциональных языках программирования). Может быть, есть какой-то известный язык, где подобное реализовано?

На вскидку два варианта:
1)Передавать контекст через аргументы выражения(как это принято в ФП).
2)Скрыть контекст за какой ни будь абстракцией(какой именно зависит от того что это за устройство, какие возможности требуются от ЯП и т.п.).

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

__>Мне нужно, чтобы в этом языке можно было легко задавать следующее условие: "для определения ситуации вычисли данное выражение E в контексте С1, затем в контексте C2 и сравни результат". Вопрос, как в декларативном программировании проще и естественнее ввести понятие контекста (будет ли это тогда вообще декларативным программированием?). Какие подводные камни здесь могут быть (по аналогии с подводными камнями в виде побочных эффектов в нечистых функциональных языках программирования). Может быть, есть какой-то известный язык, где подобное реализовано?

Описанная тобой задача прекрасно решается на Прологе.

Чтобы сказать что-то большее нужно больше информации.

2deniok

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

2AlexCab
Под декларативным я понимал язык, не задействующий ячейки памяти и работу с потоком управления. В этом смысле функциональный язык — частный случай декларативного. Декларативное — это все то, что "не императивное"

VD>На вскидку два варианта:
VD>1)Передавать контекст через аргументы выражения(как это принято в ФП).

Это как? Можно поподробнее? Как в функциональных языках вводится понятие контекста и как синтаксически осуществляется работа с ним?

2VladD2

VD>Описанная тобой задача прекрасно решается на Прологе.

А можно примерчик для имеющих только общее представление о Прологе? Что там понимается под контекстом, и как оформляется работа с ним.

VD>Чтобы сказать что-то большее нужно больше информации.

Значит так:

контекст в моем случае однозначно задается целым числом (С0, C1, C2,....). Предполагается наличие built-in функций, вычисление которых зависит от контекста. И предполагается, что пользователь языка сможет писать арифметические выражения, включающие в том числе и эти зависящие от контекста функции. И вот нужно как-то так определить синтаксис и семантику, чтобы достаточно просто было задавать вычисление выражения в заданном контексте.

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

1. Блок определения синонимов арифметических выражений (для сокращения записи повторно использующихся выражений)

E1: fun_foo[1] + fun_foo[3]
E2: fun_foo[2] + fun_foo[4]
E3: 2*E1 + 3*E2

2. Блок определения синонимов логических выражений:

L1: (E1 < E2)
L2: L1 OR (E3 > 10)

3. Основной блок (условие на ситуацию -> действие на ситуацию)

[@C0 E3] < [@C2 E3] -> "ускорить процесс"
[@C0 L2] OR [@C0 L1 AND L2] -> "замедлить процесс"

Здесь fun_foo — некоторая встроенная функция, зависящая от контекста; конструкция [@<context_id> <expression>@] является выражением, вычисление которого сводится к вычислению выражения <expression> в контексте <context_id>.

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

Здравствуйте, _hum_

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

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

D>Если явная передача контекста в каждое вычисление слишком замусоривает код, то можно посмотреть в сторону монады Reader (Хаскелл). С помощью нее легко описать вычисление, допускающее чтение значений из заданного окружения (контекста).

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

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

AC>ИМХО, "без использования понятия именованных изменяемых ячеек памяти" это не про декларативный подход, это про функциональный.

Под декларативным я понимал язык, не задействующий ячейки памяти и работу с потоком управления. В этом смысле функциональный язык — частный случай декларативного. Декларативное — это все то, что "не императивное"

AC>На вскидку два варианта:
AC>1)Передавать контекст через аргументы выражения(как это принято в ФП).

Это как? Можно поподробнее? Как в функциональных языках вводится понятие контекста и как синтаксически осуществляется работа с ним?

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

VD>Описанная тобой задача прекрасно решается на Прологе.

А можно примерчик для имеющих только общее представление о Прологе? Что там понимается под контекстом, и как оформляется работа с ним.

VD>Чтобы сказать что-то большее нужно больше информации.

Значит так:

контекст в моем случае однозначно задается целым числом (С0, C1, C2,....). Предполагается наличие built-in функций, вычисление которых зависит от контекста. И предполагается, что пользователь языка сможет писать арифметические выражения, включающие в том числе и эти зависящие от контекста функции. И вот нужно как-то так определить синтаксис и семантику, чтобы достаточно просто было задавать вычисление выражения в заданном контексте.

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

1. Блок определения синонимов арифметических выражений (для сокращения записи повторно использующихся выражений)

E1: fun_foo[1] + fun_foo[3]
E2: fun_foo[2] + fun_foo[4]
E3: 2*E1 + 3*E2

2. Блок определения синонимов логических выражений:

L1: (E1 < E2)
L2: L1 OR (E3 > 10)

3. Основной блок (условие на ситуацию -> действие на ситуацию)

[@C0 E3] < [@C2 E3] -> "ускорить процесс"
[@C0 L2] OR [@C0 L1 AND L2] -> "замедлить процесс"

Здесь fun_foo — некоторая встроенная функция, зависящая от контекста; конструкция [@<context_id> <expression>@] является выражением, вычисление которого сводится к вычислению выражения <expression> в контексте <context_id>.

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

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

__>А можно примерчик для имеющих только общее представление о Прологе? Что там понимается под контекстом, и как оформляется работа с ним.

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

VD>>Чтобы сказать что-то большее нужно больше информации.

__>Значит так:

__>контекст в моем случае однозначно задается целым числом (С0, C1, C2,....). Предполагается наличие built-in функций, вычисление которых зависит от контекста. И предполагается, что пользователь языка сможет писать арифметические выражения, включающие в том числе и эти зависящие от контекста функции. И вот нужно как-то так определить синтаксис и семантику, чтобы достаточно просто было задавать вычисление выражения в заданном контексте.

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

AC>>1)Передавать контекст через аргументы выражения(как это принято в ФП).
__>Это как? Можно поподробнее? Как в функциональных языках вводится понятие контекста и как синтаксически осуществляется работа с ним?
Например:

  myContext = <some context>
  myFun(myContext,<some other arguments>)

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

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

AC>>>1)Передавать контекст через аргументы выражения(как это принято в ФП).
__>>Это как? Можно поподробнее? Как в функциональных языках вводится понятие контекста и как синтаксически осуществляется работа с ним?
AC>Например:
AC>

AC>  myContext = <some context>
AC>  myFun(myContext,<some other arguments>)
AC>

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

AC>Но, думаю лучше было бы обойтись без контекстов, опишите подробней задачу и предметную область, я постараюсь помочь с дизайном ЯП.

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

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

1) если ($intencity_sensor > 100), то воздействие A1 /*отключить питание по каналу 1*/;
2) если ...
...

(Здесь $<sensor_name> — текущее значение датчика <sensor_name>.)

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

1) если ($intencity_sensor > 100) AND "при воздействии A1 интенсивность процесса будет не меньше 50", то воздействие A1;
2) если ...
...

Значения прогнозных показателей дают функции, например, get_intensity[], но ясно, что значения этих функций зависят от того, "в контексте какого будущего" они вычисляются. И тут, как мне видится, все-таки экспрессивнее задавать контекст для функций, а не передавать его аргументом, поскольку одно и то же условие может проверяться для нескольких вариантов "будущего":

1) если ($intencity_sensor > 100) AND [@A1 NOT (get_intensity[]  < 50) @], то воздействие A1
2) если ($intencity_sensor > 100) AND [@A2 NOT (get_intensity[]  < 50) @], то воздействие A2

Это можно было бы тогда оформить более коротко:

L1:= $intencity_sensor > 100 /*условие выхода за верхнюю границу номинального диапазона*/
L2:= get_intensity[]  < 50   /*прогнозное условие выхода за нижнюю границу номинального диапазона*/

1) если L1 AND [@A1 NOT L2 @], то воздействие A1
2) если L1 AND [@A2 NOT L2 @], то воздействие A2

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

П.П.С. Склоняюсь к языку наподобие языка выражений в Mathematica, который позволяет сократить программу, не вводя механизма пользовательских функций, а обходясь только механизмом подстановок "/.". Но пока изучаю данный вопрос.

__> Значения прогнозных показателей дают функции, например, get_intensity[], но ясно, что значения этих функций зависят от того, "в контексте какого будущего" они вычисляются. И тут, как мне видится, все-таки экспрессивнее задавать контекст для функций, а не передавать его аргументом, поскольку одно и то же условие может проверяться для нескольких вариантов "будущего":

__>

__>1) если ($intencity_sensor > 100) AND [@A1 NOT (get_intensity[]  < 50) @], то воздействие A1
__>2) если ($intencity_sensor > 100) AND [@A2 NOT (get_intensity[]  < 50) @], то воздействие A2
__>

Вот эту часть про "контексты будущего" я не совсем понял, расскажите подробнее как работает get_intensity[].

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

__>> Значения прогнозных показателей дают функции, например, get_intensity[], но ясно, что значения этих функций зависят от того, "в контексте какого будущего" они вычисляются. И тут, как мне видится, все-таки экспрессивнее задавать контекст для функций, а не передавать его аргументом, поскольку одно и то же условие может проверяться для нескольких вариантов "будущего":

__>>

__>>1) если ($intencity_sensor > 100) AND [@A1 NOT (get_intensity[]  < 50) @], то воздействие A1
__>>2) если ($intencity_sensor > 100) AND [@A2 NOT (get_intensity[]  < 50) @], то воздействие A2
__>>

AC>Вот эту часть про "контексты будущего" я не совсем понял, расскажите подробнее как работает get_intensity[].

Механизм таков: по заданному воздействию A1 производится моделирование развития процесса в будущем с учетом этого воздействия, после чего функция get_intensity[] из результата моделирования "достает" нужную характеристику процесса, в данном случае интенсивность.

Выражение [@<action> <expression> @] фактически означает "промоделируй процесс с учетом воздействия <action> и в контексте полученного результата моделирования вычисли <expression>".

Да, навtрное не совсем удачно назвал. Надо бы вместо get_intensity[] использовать более подходящее по смыслу get_intensity_prospective[].

Здравствуйте, _hum_, Вы писали:
Вопрос, как в декларативном программировании проще и естественнее ввести понятие контекста (будет ли это тогда вообще декларативным программированием?).

Контекст (в контексте вашей задачи

) — это вычислитель, которому передается задание на вычисление. Задание на вычисление проще всего оформить в виде указателя на функцию. Обращение к вычислителю — в виде вызова функции:

task=(){do something; return 1};
res1=context1.compute(task);
res2=context2.compute(task);

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

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

rfq>Здравствуйте, _hum_, Вы писали:
rfq> Вопрос, как в декларативном программировании проще и естественнее ввести понятие контекста (будет ли это тогда вообще декларативным программированием?).

rfq>Контекст (в контексте вашей задачи

) — это вычислитель, которому передается задание на вычисление. Задание на вычисление проще всего оформить в виде указателя на функцию. Обращение к вычислителю — в виде вызова функции:

rfq>

rfq>task=(){do something; return 1};
rfq>res1=context1.compute(task);
rfq>res2=context2.compute(task);
rfq>

rfq>В процессе вычисления задание обращается к каким-то стандартным функциям контекста, и у разных контекстов эти функции могут быть разными. Таким образом, сам контекст передавать во все вызовы функций не нужно.

Это псевдо-код с какого языка? Ибо, например, в том же С++, насколько я себе представляю, при передаче функции по указателю контекст ее исполнения при вызове не изменяется.

//////////////////////////////////////////////////
class CContext
{
public:
  std::string do_something(){return "Context scope";}

  std::string compute(std::string (*task)(void)){ return (*task)();}
};
//////////////////////////////////////////////////

std::string do_something(){return "Global scope";}

std::string task(void){ return do_something();}

void main(void)
{
   cout<<CContext().compute(&task);
}

//> Global scope

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

Итак, в общем:
Вашими пользовательскими будут люди далёкие от программирования и в тоже время специалисты в своей предметной области, потому стоит опираться на известные им языки: естественный(в т.ч. жаргон и сленг принятые в пр. области) и математический. В частности, думаю стоит избавится от редкоиспользуемых символов вроде "$", "@", "[]" и т.п. И давить сущностным такие имена которые наиболее часто используются в переметной области, например обычно говорят просто "если интенсивность больше..." а не "если значение датчика интенсивности больше...".

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

<заглавие с именем модели>
<параметры>
<описание входов-выходов>
<тело программы>

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

Пример:
Задача: сделать регулятор температуры, который при помощи пары нагревателей(сильного и слабого), поддерживающий +23*(+2-1), и выдающий сигналы "холодно" и "жарко" при +13* и +33* соответственно.
Есть контроллер имеющий четыре входа(I0..I3) и четыре выхода(O0..O3), и модель "hot objects with two heaters". Эта модель не имеет алгоритма регулирования, а только позволяет пересказывать температуру объекта нагреваемого парой нагревателей, и содержит следующий специфический синтаксис:
Входы-выходы(обязательно должны быть назначены на какие ни будь реальные входы-выходы контроллера):
"temperature" — значение температуры,
"first_heater", "second_heater" — первый и второй нагреватели.
Парамтры:
"object_coefficient" — некий коэффициент характеризующей нагреваемый объект,
"first_heater_power", "second_heater_power" — мощьность первого и второго нагреватиля,
ну так далее.
А так же функцию "be" вычисляющую какой будет температура, если произойдёт действие указанное в том же выражении.
Программа на основе этой модели может выглядеть примерно так:

hot_objects_with_two_heaters                                   //Заглавие
Parameters:
  object_coefficient = 123
  first_heater_power = 1000
  second_heater_power = 500
Ins-outs:
  I1 = temperature                                             //Вариант синтаксиса: I1:temperature
  O1 = first_heater
  O2 = second_heater
  O3 = coldly
  O4 = hot
Program:
  check = temperature < 22 and temperature be < 25             //Вариант синтаксиса: check = (temperature < 22) and (temperature be < 25)
  on first_heater if check                                     //Подстановка ранее определённого выражения как если бы оно было написано здесь(как в математике). 
  on second_heater if check 
  off first_heater if temperature > 23                         //Вариант синтаксиса: (temperature > 23) -> first_heater off
  off second_heater if temperature > 24 and temperature be < 25  
  on coldly if temperature < 13
  off coldly if temperature > 13
  on hot if temperature > 33
  off hot if temperature < 33

Можно так-же добавить возможность предсказывать и по отношению к другим событиям, например:

  off second_heater if temperature > 24 and if off first_heater temperature be < 25 
     //Как вариант синтаксиса: (temperature > 24)and(temperature be(if off first_heater) < 25) -> second_heater off

PS: Если вам что-то пригодится из этого, не забудьте отписать что именно и как, интересно же!

.

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

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

К сожалению, вы не так поняли. Модель одна. А пользователю, грубо говоря, надо дать возможность задавать условия вида
1) если "температура < 30" AND "давление < 100, при поднятии контроллером температуры на 70 градусов", то поднять температуру на 70 градусов;
2) если "температура < 30" AND "давление < 100, при поднятии контроллером температуры на 35 градусов", то поднять температуру на 35 градусов;

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

Кратко это записывается:

1) если "температура < 30" AND [давление < 100 | в контексте повышения температуры на 70 градусов], то ...
2) если "температура < 30" AND [давление < 100 | в контексте повышения температуры на 735 градусов], то ...

На всяк случай: Модель это набор данных(например, скорость, давление etc.) отражающих состояние тех. процесса(например, процесса поддержания температуры некоторого объекта), и алгоритмов отражающих поведение тех. процесса(включая алгоритм(ы) предсказания "что будет если..."), некоторые или все из которых доступны пользователю ЯП посредством соответствующих идентификаторов (т.е. синтаксиса ЯП).

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

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

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

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

__>А можно примерчик для имеющих только общее представление о Прологе? Что там понимается под контекстом, и как оформляется работа с ним.
Из того что я понял пролог тут не нужен.

__>контекст в моем случае однозначно задается целым числом (С0, C1, C2,....). Предполагается наличие built-in функций, вычисление которых зависит от контекста. И предполагается, что пользователь языка сможет писать арифметические выражения, включающие в том числе и эти зависящие от контекста функции. И вот нужно как-то так определить синтаксис и семантику, чтобы достаточно просто было задавать вычисление выражения в заданном контексте.
Я правильно понял, что эти контексты не меняются во время вычислений?
Если да то никаких побочных эффектов тут нет.

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

__>1. Блок определения синонимов арифметических выражений (для сокращения записи повторно использующихся выражений)
__>2. Блок определения синонимов логических выражений:
Не вижу между ними разницы.

__>3. Основной блок (условие на ситуацию -> действие на ситуацию)
Что делать если сработает больше одного условия?

__>Но это все мои "придумки", а потому я не уверен, что здесь нет граблей, например, в виде зависимости результата вычисления от порядка вычисления выражений (аппликативного/нормального), ведь в моем случае есть же зависимость функций от контекста, а это очень близко к побочным эффектам (которые, как известно, как раз-таки делают зависимым результат от порядка вычисления).
Нет тут побочных эффектов.
Все твои "синонимы" это чистые функции. А [@<context_id> <expression>@] просто передает в каждую функцию неявный аргумент.

__>Хотелось бы все-таки узнать, как это решается стандартным способом. К тому же хочется ввести механизм для уменьшения дублирования выражений. А тут тоже — подходов много (например, введение классического механизма функций, введение макросов, введение шблонов правил вывода выражений как в Mathematica) и какой из них выбрать так, чтобы был прост и в семантическом, и в синтаксическом плане, и не наплодил ловушек для неискушенного программиста...
Просто создай функции.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, _hum_, Вы писали:
__>Но столкнулся со следующей трудностью. Мне нужно, чтобы в этом языке можно было легко задавать следующее условие: "для определения ситуации вычисли данное выражение E в контексте С1, затем в контексте C2 и сравни результат".

Прочитал тему. Переусложнили вы, имхо. Нет у вас контекста, у вас есть условия. Не "температура в контексте давление больше чего-то там", а "температура при давлении равном чему-то там". И записывается оно в два счета T(P=10). И алгоритм реализации прост как две копейки -- вызов без параметров это показание датчика, вызов с именованными параметрами это расчет по какой-то формуле, где заданные параметры берутся из аргументов, а значения незаданных из текущего состояния датчиков.

Если показатель P1 датчика D1 рассчитывается по формуле P1 = F(A1, A2, ..., An) то будет где-то так

если P1 < 10 то //делаем что-то
//в данном случае P1 = D1
если /*какие-то условия*/ и P1(A1 = 1) < 10 то //делаем что-то другое
// в данном случае P1 = F(1, A2, ..., An), 
// где A2...An текущие показания соответствующих датчиков или вычисления из текущих показаний датчиков

AC>>Т.е. ваше устройство будет строго специализированным для одного тех. процесса?
__>Да.
О, тогда можно сделать проще. Можно выкинуть из формата файла программы заглавие и блок настройки входов-выходов, оставив параметры модели и собственно программу.
AC>>А как вы, планируете реализовать проверку будущего состояния?
__>С помощью моделирования — модель же процесса имеется, так что не представляет труда по ней просчитать будущие состояния.
__>(На всякий случай: под моделью здесь понимается физическая (математическая) модель процесса, по которой можно строить оценки состояний реального процесса. У пользователя есть возможность задавать некоторые факторы, влияющие на функционирование модели, и получать оценки конкретных ее характеристик в будущем.)
Вот эту модель я и предлагаю считать контекстом, а ни какое-то конкретное событие, т.е. "что будет с процессом если сделать нечто" а не просто "что будет если сделать нечто". Таким образом контекст будет не явным и общим для всей программы, его не нужно будет никуда передавать(например для предсказания достаточно просто указать значение какой характеристики процесса которую требуется предсказать и (возможно) после какого события).
Например вместо:
__>1) если "температура < 30" AND "давление < 100, при поднятии контроллером температуры на 70 градусов", то поднять температуру на 70 градусов;
можно короче, без явного указания события:
если "температура < 30" AND "давление будет < 100", то поднять температуру на 70 градусов;
и с явным указанием события:
если "температура < 30" AND "если открыть_клапан давление будет < 100", то поднять температуру на 70 градусов;

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

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

rfq>>Здравствуйте, _hum_, Вы писали:
rfq>> Вопрос, как в декларативном программировании проще и естественнее ввести понятие контекста (будет ли это тогда вообще декларативным программированием?).

rfq>>Контекст (в контексте вашей задачи

) — это вычислитель, которому передается задание на вычисление. Задание на вычисление проще всего оформить в виде указателя на функцию. Обращение к вычислителю — в виде вызова функции:

rfq>>

rfq>>task=(){do something; return 1};
rfq>>res1=context1.compute(task);
rfq>>res2=context2.compute(task);
rfq>>

rfq>>В процессе вычисления задание обращается к каким-то стандартным функциям контекста, и у разных контекстов эти функции могут быть разными. Таким образом, сам контекст передавать во все вызовы функций не нужно.

__>Это псевдо-код с какого языка? Ибо, например, в том же С++, насколько я себе представляю, при передаче функции по указателю контекст ее исполнения при вызове не изменяется.

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

Контекст функции не меняется во многих (почти во всех) языках, но у вас и
задача нестандартная, не стоит ожидать, что вам уже приготовили средства
для ее решения.
Хотя вот в Jav'e есть ThreadLocal — контекст, привязанный к потоку
исполнения, вполне его можно использовать. В крайнем случае ссылку на
контекст можно записать в глобальную переменную, и менять ее перед
вызовом, но это некрасиво. Можно контекст передавать параметром при каждом
вызове функции, но скрыть это от пользователя — у вас ведь свой язык,
можно добавлять эти параметры при генерации кода (и неважно, во что вы
генерируете — x86, java байткод или С++).

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

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

__>>контекст в моем случае однозначно задается целым числом (С0, C1, C2,....). Предполагается наличие built-in функций, вычисление которых зависит от контекста. И предполагается, что пользователь языка сможет писать арифметические выражения, включающие в том числе и эти зависящие от контекста функции. И вот нужно как-то так определить синтаксис и семантику, чтобы достаточно просто было задавать вычисление выражения в заданном контексте.
WH>Я правильно понял, что эти контексты не меняются во время вычислений?
WH>Если да то никаких побочных эффектов тут нет.

Само содержимое контекстов не меняется. И да, побочных эффектов здесь нет, но есть зависимость от контекста, а значит, не совсем очевидно, что порядок вычисления (нормальный/аппликативный) не будет влиять на результат (есть свойство конфлюэнтности wiki/Confluence).

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

__>>1. Блок определения синонимов арифметических выражений (для сокращения записи повторно использующихся выражений)
__>>2. Блок определения синонимов логических выражений:
WH>Не вижу между ними разницы.

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

__>>3. Основной блок (условие на ситуацию -> действие на ситуацию)
WH>Что делать если сработает больше одного условия?

Как обычно — тогда выполняется первое по тексту.

__>>Но это все мои "придумки", а потому я не уверен, что здесь нет граблей, например, в виде зависимости результата вычисления от порядка вычисления выражений (аппликативного/нормального), ведь в моем случае есть же зависимость функций от контекста, а это очень близко к побочным эффектам (которые, как известно, как раз-таки делают зависимым результат от порядка вычисления).
WH>Нет тут побочных эффектов.
WH>Все твои "синонимы" это чистые функции. А [@<context_id> <expression>@] просто передает в каждую функцию неявный аргумент.

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

__>>Хотелось бы все-таки узнать, как это решается стандартным способом. К тому же хочется ввести механизм для уменьшения дублирования выражений. А тут тоже — подходов много (например, введение классического механизма функций, введение макросов, введение шаблонов правил вывода выражений как в Mathematica) и какой из них выбрать так, чтобы был прост и в семантическом, и в синтаксическом плане, и не наплодил ловушек для неискушенного программиста...
WH>Просто создай функции.

Совсем просто...Функции — это сущности "второго порядка". Хотелось бы попробовать без них обойтись (например, как в Mathematica язык исчисления выражений с механизмом подстановок).

WH>И еще контексты лучше делать с нормальными именами. Иначе люди будут путаться с волшебными числами.
Это ясно.

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

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

rfq>Контекст функции не меняется во многих (почти во всех) языках, но у вас и
rfq>задача нестандартная, не стоит ожидать, что вам уже приготовили средства
rfq>для ее решения.
rfq>Хотя вот в Jav'e есть ThreadLocal — контекст, привязанный к потоку
rfq>исполнения, вполне его можно использовать. В крайнем случае ссылку на
rfq>контекст можно записать в глобальную переменную, и менять ее перед
rfq>вызовом, но это некрасиво. Можно контекст передавать параметром при каждом
rfq>вызове функции, но скрыть это от пользователя — у вас ведь свой язык,
rfq>можно добавлять эти параметры при генерации кода (и неважно, во что вы
rfq>генерируете — x86, java байткод или С++).

То, о чем вы ведете речь, относится к вопросу "лексическая vs динамическая область видимости (scope)". В большинстве языков (в том числе и в С++) она лексическая, а потому не даст поменять контекст. Я так понимаю, вы предлагаете решить проблему путем ввода динамического scop-а. Но я не хотел бы, так как с ним работать очень сложно для начинающего (и не очень).

Здравствуйте, AlexCab

Наверное, не туда мы идем. Давайте, наверное так:

Есть идентификаторы a1,a2,...a10, которые в зависимости от ситуации могут быть связаны с разными значениями. Есть идентификаторы ситуаций, например, S0,S1,S3 (три ситуации) с соответствующими связываниями:
S0: a1->25, a2->34,...,a10->23
S1: a1->13, a2->17,...,a10->41
S3: a1->32, a2->12,...,a10->25
Ситуация S0 — выделенная, в том смысле, что по умолчанию она все время подразумевается.

И есть выражения, которые могут включать эти идентификаторы, например,

E1: a1*a2*a3*..*a10.
E2: a1+a2+a3
E3: a6^a7
E4: E2 + E3
L1: E1 + E3 < E4
L2: E1*E2*E3*E4 < (E1+E2)*E3^E4

Спрашивается, как наиболее просто и естественно организовать в языке конструкции наподобие:

"(значение логического выражения L1 в ситуации S1) AND (значение логического выражения L1 в ситуации S2) OR 
 (значение логического выражения L2 в ситуации по умолчанию)"

?

Мне кажется, что должно быть что-то наподобие

[@S1 L1] AND [@S2 L2] OR L2

Внимательно слушаю ваши конкретные варианты.

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

WH>>Все твои "синонимы" это чистые функции. А [@<context_id> <expression>@] просто передает в каждую функцию неявный аргумент.
__>Ну, вообще-то, чистые функции — это те, которые при вызове с одними и теми же аргументами возвращают одно и то же значение.
Контекст это тоже аргумент функции.
Только передается не явно.

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

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

__>Совсем просто...Функции — это сущности "второго порядка". Хотелось бы попробовать без них обойтись (например, как в Mathematica язык исчисления выражений с механизмом подстановок).
Да без разницы на самом деле.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

__>Внимательно слушаю ваши конкретные варианты.
Да так и пишешь.
После чего во время компиляции превращаешь контекст в структуру.
Создаешь ее экземпляры.
И переписываешь во время компиляции, во что-то типа такого:

E1(context): context.a1*context.a2*context.a3*..*context.a10
E2(context): context.a1+context.a2+context.a3
E3(context): context.a6^context.a7
E4(context): E2(context) + E3(context)
L1(context): E1(context) + E3(context) < E4(context)
L2(context): E1(context)*E2(context)*E3(context)*E4(context) < (E1(context)+E2(context))*E3(context)^E4(context)
L1(S1) AND L2(S2) OR L2(S0)

Дальше всё просто.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

__>Наверное, не туда мы идем. Давайте, наверное так:
__>Есть идентификаторы a1,a2,...a10, которые в зависимости от ситуации могут быть связаны с разными значениями. Есть идентификаторы ситуаций, например, S0,S1,S3 (три ситуации) с соответствующими связываниями:
__>S0: a1->25, a2->34,...,a10->23
__>S1: a1->13, a2->17,...,a10->41
__>S3: a1->32, a2->12,...,a10->25
__>Ситуация S0 — выделенная, в том смысле, что по умолчанию она все время подразумевается.
ИМХО это(когда значения характеризующее модель зависят от ситуации, а не от стояния модели) не логично, потому что именно изменения в модели приводит к изменению её характеристик.
__>Спрашивается, как наиболее просто и естественно организовать в языке конструкции наподобие:
__>Мне кажется, что должно быть что-то наподобие
__>

__>[@S1 L1] AND [@S2 L2] OR L2
__>

Думаю это будет плохо читаться, лучше так:

(L1 in case S1) AND (L2 in case S2) OR L2

или так:

(L1 for S1) AND (L2 for S2) OR L2

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

WH>Явность для обеспечения чистоты не нужна.

Ну, значит, у вас отличное от того же википедийного понимание чистоты функции.

In computer programming, a function may be described as pure if both these statements about the function hold:

1. The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change as program execution proceeds or between different executions of the program, nor can it depend on any external input from I/O devices.

Пример. Функция f не имеет побочного эффекта, но в то же время из-за зависимости от контекста не является чистой.

int a = 0;

int f(int x){return a + x;}

void main(void)
{
  a = f(1);// f(1) -> 1
  a = f(1);// f(1) -> 2
}

__>>Внимательно слушаю ваши конкретные варианты.
WH>Да так и пишешь.
WH>После чего во время компиляции превращаешь контекст в структуру.

Мне сама компиляция не интересна, мне главное определиться с синтаксисом и семантикой языка. Вариант с синтаксисом наподобие [@<ситуация> <expression>] меня смущает тем, что у этой конструкции не очевидно в общем случае, какая должна быть семантика.
То ли,
1) "выражение <expression> преобразуется до тех пор, пока можно, после чего в нем заменяется вхождение всех символов на значения по ситуации <ситуация>", то ли
2) "в выражении <expression> заменяется вхождение всех символов на значение по ситуации <ситуация>, после чего производится его вычисление".

Для программы с S0: a1 ->25, S1: a1-> 13

E1: a1 + 1

[@S1 E1]

семантика 1) дает:

[@S1 E1] -> [@S1 a1 + 1] -> 13 + 1 -> 14

семантика 2) дает:

[@S1 E1] -> E1 -> (вспоминаем, что по умолчанию считается, E1 = [@S0 E1])-> a1 + 1 -> 25 + 1 -> 26

Для вложенных конструкций наподобие

[@S1 2*[@S3 a1 + 2] ]

тоже
в случае 1)

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

в случае 2)

[@S1 2*[@S3 a1 + 2] ] -> 2*[@S3 13 + 2] -> 2*(13 + 2) -> 2*15 -> 30.

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

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

__>>Спрашивается, как наиболее просто и естественно организовать в языке конструкции наподобие:
__>>Мне кажется, что должно быть что-то наподобие
__>>

__>>[@S1 L1] AND [@S2 L2] OR L2
__>>

AC>Думаю это будет плохо читаться, лучше так:
AC>

AC>(L1 in case S1) AND (L2 in case S2) OR L2
AC>

AC>или так:
AC>

AC>(L1 for S1) AND (L2 for S2) OR L2
AC>

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

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

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

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

__>К сожалению, вы не так поняли. Модель одна. А пользователю, грубо говоря, надо дать возможность задавать условия вида
__>1) если "температура < 30" AND "давление < 100, при поднятии контроллером температуры на 70 градусов", то поднять температуру на 70 градусов;
__>2) если "температура < 30" AND "давление < 100, при поднятии контроллером температуры на 35 градусов", то поднять температуру на 35 градусов;

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

__>Кратко это записывается:

__>1) если "температура < 30" AND [давление < 100 | в контексте повышения температуры на 70 градусов], то ...
__>2) если "температура < 30" AND [давление < 100 | в контексте повышения температуры на 735 градусов], то ...
Мне кажется, что вы идёте не в ту сторону. Ну, то есть может быть есть какие-то другие ситуации, но вы приводите довольно-таки однообразные штуки. В них есть
1. Условие на момент начала предполагаемого действия — предусловие.
2. Условие на момент конца предполагаемого действия — постусловие.
3. И, собственно, само действие.
Вы зачем-то склеиваете 1 и 2, из-за этого у вас возникает необходимость дважды упоминать действие.
Разве вам надо иметь возможность писать код типа:

если "температура < 30" AND "давление < 100, при поднятии контроллером температуры на 70 градусов", то поднять температуру на 1500 градусов;

?
Если нет — то лучше будет описывать правила как-то так:

if <predicate> then <action> unless <guard>

Типа

ЕСЛИ (модель.бомба != ОТСУТСТВУЕТ) И (модель.пила != ОТСУТСТВУЕТ) ТО модель.Пилить(бомба, пила) ЕСЛИ_ЭТО_НЕ_ПРИВЕДЁТ_К (модель.бомба.взорвалась)
IF (model.Temperature < 30C) THEN model.IncreaseTemperatureBy(70C) UNLESS model.Pressure >= 100;

То есть предикат слева всегда выполняется в настоящем, а предикат справа — в том единственном будущем, которое наступит после внесения рассматриваемого изменения.
Это покрывает ваши нужды?

Здравствуйте, Sinclair, Вы писали:
[...]
S>Это покрывает ваши нужды?

Нет, так не пойдет. Нужно уметь еще записывать что-то наподобие
"если <expression> в контексте будущего 1 <= <expression> в контексте будущего 2, то выбрать действие, приводящее к будущему 1"
то есть, элемент оптимизации — из нескольких вариантов действий контроллер должен выбрать то, которое приведет к оптимальному значению выражения в будущем.

AC>>Думаю это будет плохо читаться, лучше так:
AC>>

AC>>(L1 in case S1) AND (L2 in case S2) OR L2
AC>>

__>Это уже синтаксический сахар.
Нет, зачем вообще в таком маленьком ЯП с. сахар?
__>Но в целом, раз вы согласны с таким вариантом,
Не согласен, считаю что лучшим решением был-бы остро заточение DSL, вы же хотите напихать в ЯП лишние, не нужные вещи, на вроде контекстов.
Но не суть.
__>тогда ответьте, пожалуйста, на мои возражения по его поводу в моем предыдущем посте.
В этом варианте думаю лучше будет всё таки ввести функции. Эта концепция должна быть известна пользователям из школьного и институтского курса математики, и отличается от вашего варианта только тем что значения(аргументы) передаются явно, что в свою очередь хорошо для читабельности(не будет возникать вопросов типа "откуда берутся эти "a1","a2","a3""). Не стоит боятся лишних букв, так как 1)значений в вашей предметной области обычно не бывает много, 2)Ctrl+C — Ctrl+V, 3)это даёт возможность назвать аргументы в функции иначе чем они называются в месте вызова, 4)в функции выносится только то что многократно используется, 5)можно подготовить набор типовых функций и спрятать их в библиотеку(с подстановкой так не получится из-за конфликтов имён).
Например:

E1(a1,a2,a3,..,a10) = a1*a2*a3*..*a10
E2(a1,a2,a3) = a1+a2+a3
E3(a6,a7) = a6^a7
E4(a1,a2,a3,a6,a7) = E2(a1,a2,a3) + E3(a6,a7)
L1(a1,a2,a3,..,a10) = E1(a1,a2,a3,..,a10) + E3(a6,a7) < E4(a1,a2,a3,a6,a7)
L2(a1,a2,a3,..,a10) = E1(a1,a2,a3,..,a10)*E2(a1,a2,a3)*E3(a6,a7)*E4(a1,a2,a3,a6,a7) < (E1(a1,a2,a3,..,a10)+E2(a1,a2,a3))*E3(a6,a7)^E4(a1,a2,a3,a6,a7) //Жуть, таких выражения наверно даже в теор. физике не встретить :)

А ситуации представить в виде структур, а в help написать что это такие векторы(пользователям должны быть известны из курса мат. анализа), но с именами элементов.
Например:

S0=[a1=25, a2=34,...,a10=23] 
S1=[a1=13, a2=17,...,a10=41]
S2=[a1=32, a2=12,...,a10=25]

Тогда условия будут выглядеть так:

L1(S1 a1,S1 a2,S1 a3,..,S1 a10) AND L2(S2 a1,S2 a2,S2 a3,..,S2 a10) OR L2(a1,a2,a3,..,a10)

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

Передавать придётся не весь контекст а только значения необходимые функции.

в случае 1)[@S1 2*[@S3 a1 + 2] ] -> [@S1 2*(32+2) ] -> [@S1 2*34 ] -> [@S1 68 ] -> 68
в случае 2)[@S1 2*[@S3 a1 + 2] ] -> 2*[@S3 13 + 2] -> 2*(13 + 2) -> 2*15 -> 30.
Короче, какая-то бяка, которая может сильно усложнить понимание работы программы.

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

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

И у вас получится новый С++, ИМХО лучше выбрать что-то одно или подстановку или функции.

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

__>Нет, так не пойдет. Нужно уметь еще записывать что-то наподобие
__>"если <expression> в контексте будущего 1 <= <expression> в контексте будущего 2, то выбрать действие, приводящее к будущему 1"
__>то есть, элемент оптимизации — из нескольких вариантов действий контроллер должен выбрать то, которое приведет к оптимальному значению выражения в будущем.
Ну, так это же замечательно. Всё ложится в ту же канву. Так и пишите:

ИЗ <действие1>, <действие2>, <действие3>
  ВЫПОЛНИТЬ ЛУЧШЕЕ ПО <критерий>

Где <критерий> всегда вычисляется в пост-контексте.
Каждое из <действий> может быть точно также оборудовано пре- и пост-условиями.
Результат такой конструкции тоже является "действием", и может оборудоваться предусловием и пост-условием.
Тот псевдо-язык, который вы предлагаете, скрывает суть происходящего за какими-то лишними деталями, избыточно многословен, и позволяет легко ошибиться из-за д:
"если <expression1> в контексте будущего 1 <= <expression2> в контексте будущего 2, то выбрать действие, приводящее к будущему 3"

Когда вы перестанете фокусироваться на второстепенных деталях синтаксиса, а внятно опишете семантику (т.е. что конкретно должен уметь язык), мы придём к языку, который будет как минимум не хуже SQL.
Приведите как можно больше примеров как можно более реальных программ, которые вы хотите написать на этом языке.

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

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

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

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

__>Короче, какая-то бяка, которая может сильно усложнить понимание работы программы. К тому же, если в дальнейшем потребуется расширить язык (ввести пользовательские функции, блоки с областями видимости, namespace и проч.), то не исключено, что может случиться конфликт между ними.
Если сделаешь, как я сказал, то у тебя всё получится автоматом.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

AC>>>Думаю это будет плохо читаться, лучше так:
AC>>>

AC>>>(L1 in case S1) AND (L2 in case S2) OR L2
AC>>>

__>>Это уже синтаксический сахар.
AC>Нет, зачем вообще в таком маленьком ЯП с. сахар?

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

__>>Но в целом, раз вы согласны с таким вариантом,
AC>Не согласен, считаю что лучшим решением был-бы остро заточение DSL, вы же хотите напихать в ЯП лишние, не нужные вещи, на вроде контекстов.
AC>Но не суть.
Это я не понял.
__>>тогда ответьте, пожалуйста, на мои возражения по его поводу в моем предыдущем посте.
AC>В этом варианте думаю лучше будет всё таки ввести функции. Эта концепция должна быть известна пользователям из школьного и институтского курса математики, и отличается от вашего варианта только тем что значения(аргументы) передаются явно, что в свою очередь хорошо для читабельности(не будет возникать вопросов типа "откуда берутся эти "a1","a2","a3""). Не стоит боятся лишних букв, так как 1)значений в вашей предметной области обычно не бывает много, 2)Ctrl+C — Ctrl+V, 3)это даёт возможность назвать аргументы в функции иначе чем они называются в месте вызова, 4)в функции выносится только то что многократно используется, 5)можно подготовить набор типовых функций и спрятать их в библиотеку(с подстановкой так не получится из-за конфликтов имён).
AC>Например:
AC>

AC>E1(a1,a2,a3,..,a10) = a1*a2*a3*..*a10
AC>E2(a1,a2,a3) = a1+a2+a3
AC>E3(a6,a7) = a6^a7
AC>E4(a1,a2,a3,a6,a7) = E2(a1,a2,a3) + E3(a6,a7)
AC>L1(a1,a2,a3,..,a10) = E1(a1,a2,a3,..,a10) + E3(a6,a7) < E4(a1,a2,a3,a6,a7)
AC>L2(a1,a2,a3,..,a10) = E1(a1,a2,a3,..,a10)*E2(a1,a2,a3)*E3(a6,a7)*E4(a1,a2,a3,a6,a7) < (E1(a1,a2,a3,..,a10)+E2(a1,a2,a3))*E3(a6,a7)^E4(a1,a2,a3,a6,a7) //Жуть, таких выражения наверно даже в теор. физике не встретить :)
AC>

Вы же сами признали, что выглядит все жутко. А теперь представьте себе, что эту жуть придется редактировать (а тем более другому человеку). Даже такая элементарная операция как добавление нового условия наподобие E5: E3 + E2 становится нетривиальной — придется просматривать, какие именно "а"-шки используются в E1 и E2, чтобы правильно указать E5(a1,a2,a3,a6,a7). Да и вообще, в вашем варианте это не функции, поскольку при определении функции указываются параметры, а не аргументы. То есть, канонически, если отталкиваться от функций, должно было бы быть так:
сначала определяется функция

E3(p1_, p2_) = p1^p2 // функция с параметрами p1, p2

а уже потом записывается выражение

E3(a6,a7)// применение функции

В вашем же варианте вы определяете не функции, а правила замены "функциональных выражений" наподобие того, что делается в пакете Mathematica, когда пишется, например, f[1] = 1. А это уже, извините, в школе не проходили, и не так просто для объяснения. Например, как воспринимать запись E1(a1) = a2 как "E1(a1) везде по тексту далее заменяется на a2"? Но тогда резонный вопрос у пользователя, почему бы просто не записать E1 = a2. Если же настаивать на том, что все "а"-шки, участвующие справа, должны быть указаны в списке "а"-шек слева, то пользователь может задать резонный вопрос — так а зачем тогда вообще этот список ему указывать, если он автоматом определяется по правой части?

AC>А ситуации представить в виде структур, а в help написать что это такие векторы(пользователям должны быть известны из курса мат. анализа), но с именами элементов.
AC>Например:
AC>

AC>S0=[a1=25, a2=34,...,a10=23] 
AC>S1=[a1=13, a2=17,...,a10=41]
AC>S2=[a1=32, a2=12,...,a10=25]
AC>

Во-первых, как там представляются ситуации — векторами или другим образом — не принципиально. На момент написания программы пользователь уже знает, что ситуации заданы, и имеет четкое представление о них. То есть, у него есть вся информация о том, что значит ситуация S0 или S1. Во-вторых, я обозначил значения a1,a2,...,a10 только для удобства. На самом деле эти идентификаторы несут информацию о том, какое значение содержат. Например, "a1" <-> "Pressure", a2 <-> "Temperature" и т.д. Сами же ситуации выглядят наподобие
S1 — ситуация при включенном нагреве теном на мощность 200кВт",
S2 — ситуация при включенном нагреве теном на мощность 400Вт" и т.п.

AC>Тогда условия будут выглядеть так:
AC>

AC>L1(S1 a1,S1 a2,S1 a3,..,S1 a10) AND L2(S2 a1,S2 a2,S2 a3,..,S2 a10) OR L2(a1,a2,a3,..,a10)
AC>

Те же претензии, что и выше
— нужно правильное оформление функций;
— увеличивается громоздкость (трудно читать и редактировать).

AC>

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

AC>Передавать придётся не весь контекст а только значения необходимые функции.

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

AC>

в случае 1)[@S1 2*[@S3 a1 + 2] ] -> [@S1 2*(32+2) ] -> [@S1 2*34 ] -> [@S1 68 ] -> 68
AC>в случае 2)[@S1 2*[@S3 a1 + 2] ] -> 2*[@S3 13 + 2] -> 2*(13 + 2) -> 2*15 -> 30.
AC>Короче, какая-то бяка, которая может сильно усложнить понимание работы программы.

AC>Так вот функции устраняют эту "бяку" инкапсулируя реализацию, т.е. пользователю не нужно будет думать как оно там преобразуется, он просто послал аргументы — получил результат.

Какой ценой....(см. выше)

AC>

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

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

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

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

__>>Нет, так не пойдет. Нужно уметь еще записывать что-то наподобие
__>>"если <expression> в контексте будущего 1 <= <expression> в контексте будущего 2, то выбрать действие, приводящее к будущему 1"
__>>то есть, элемент оптимизации — из нескольких вариантов действий контроллер должен выбрать то, которое приведет к оптимальному значению выражения в будущем.
S>Ну, так это же замечательно. Всё ложится в ту же канву.
S>

S>ИЗ <действие1>, <действие2>, <действие3>
S>  ВЫПОЛНИТЬ ЛУЧШЕЕ ПО <критерий>
S>

S>Где <критерий> всегда вычисляется в пост-контексте.
Ваше "ВЫПОЛНИТЬ ЛУЧШЕЕ" похоже на "СДЕЛАТЬ_ВСЕ_ХОРОШО". Суть же в том и состоит, чтобы расписать контроллеру, как именно он должен выбирать то, что пользователь называет "лучшее".

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

Что здесь понимается под пост-условием? Проверка условия после того,к ак действие выполнено, или проверка условия в предположении, что действие произойдет, но реально оно еще не произошло?

S>Результат такой конструкции тоже является "действием", и может оборудоваться предусловием и пост-условием.
S>Тот псевдо-язык, который вы предлагаете, скрывает суть происходящего за какими-то лишними деталями, избыточно многословен, и позволяет легко ошибиться из-за д:
S>"если <expression1> в контексте будущего 1 <= <expression2> в контексте будущего 2, то выбрать действие, приводящее к будущему 3"

S>Когда вы перестанете фокусироваться на второстепенных деталях синтаксиса, а внятно опишете семантику (т.е. что конкретно должен уметь язык), мы придём к языку, который будет как минимум не хуже SQL.
S>Приведите как можно больше примеров как можно более реальных программ, которые вы хотите написать на этом языке.

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

Здравствуйте, 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 градусов. Значит расчеты модели не верны, а значит правила основанные этой модели могут не работать или работать не так как ожидалось. Что дальше я даже боюсь представить

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 17>>

Здравствуйте, _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>>Для этого нужна конкретная модель вашего тех. процесса(опишите её), из этой модели уже можно будет построить ЯП.
__>Зачем вам конкретная модель???
Затем что ЯП для программирования контроллеров управляющих чайниками, будет очень сильно отличатся от ЯП для контроллеров управляющих атомными подводными лодками.
__>Ну, раз так хотите, возьмите, например, такую — газ в подогреваемом электротеном вертикальном металлическом цилиндре с поршнем, на который положен некоторый груз.
Вы, помницо писали что у вас один тех. процесс? Потому что ЯП для описания одного тех. процесса, не то-же что для описания нескольких.
__>Да, абсолютная прозрачность — это инкапсулирование все в функцию со строгой передачей всех данных через ее аргументы. Но ведь нужно знать меру — вы же при написании функции расчета длины окружности не будете писать 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>Вы, помницо писали что у вас один тех. процесс? Потому что ЯП для описания одного тех. процесса, не то-же что для описания нескольких.

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

__>>Да, абсолютная прозрачность — это инкапсулирование все в функцию со строгой передачей всех данных через ее аргументы. Но ведь нужно знать меру — вы же при написании функции расчета длины окружности не будете писать 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)
— смоделировать эти контексты (вычислить свойства — показания датчиков)
— вычислить значения пользовательских свойств (на основе формул) для всех контекстов
— выполнить программу ЕСЛИ ... ТО

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 17>>

Здравствуйте, _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 теперь идёт по тому же пути, что я предложил — неявное указание контекста при помощи указания действия для выполнения.
Но думаю ТСу нужна именно неявная передача контекста в функцию, а не ЯП для программирования контроллеров

Здравствуйте, AlexCab, Вы писали:
AC>Но думаю ТСу нужна именно неявная передача контекста в функцию, а не ЯП для программирования контроллеров

Сам он пишет, что ему нужен ЯП для программирования контроллеров.
А передача контекстов в функцию — это архитектурная наркомания, результат неверной декомпозиции задачи на подзадачи. Прикладное значение у неё ровно одно: на порядок повысить стоимость разработки и сопровождения программ для контроллеров. Несмотря на то, что это во многих отраслях является практически приемлемым решением (иначе как объяснить заказчику, что модификация программы при добавлении в техпроцесс ещё одного манипулятора стоит $100000), этическая составляющая мне тут категорически не нравится.
Лично я всегда выступаю как адвокат пользователя, в нашем случае — программиста этих контроллеров.

AC>>Но думаю ТСу нужна именно неявная передача контекста в функцию, а не ЯП для программирования контроллеров

S>Сам он пишет, что ему нужен ЯП для программирования контроллеров.
S>А передача контекстов в функцию — это архитектурная наркомания, результат неверной декомпозиции задачи на подзадачи. Прикладное значение у неё ровно одно: на порядок повысить стоимость разработки и сопровождения программ для контроллеров. Несмотря на то, что это во многих отраслях является практически приемлемым решением (иначе как объяснить заказчику, что модификация программы при добавлении в техпроцесс ещё одного манипулятора стоит $100000), этическая составляющая мне тут категорически не нравится.
ХЗ, не исключено.

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

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

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

__>>Смотря как посмотреть

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

S>Мне кажется, вы хитрите. Физического смысла в том, чтобы не выполнять никакое действие из сравниваемых нет. То, что в моём случае всегда будет исполнено какое-то действие — однозначно есть гуд.

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

Чтобы в дальнейшем легче было вести обсуждение, попытаюсь выделить ваши претензии:
1) возможность задания вычисления выражения в контексте ака

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

2) трудность понимания сути написанного ака

S>Программы на "моём" языке легко читать и они понятны. Программы на вашем языке читать труднее, чем финансовое законодательство.
[...]
S>давайте вернёмся к вашей программе:
S>

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

S>

S>Вам очевидны намерения программиста, который её писал? Мне — нет.

3) подверженность элементарным ошибкам ака

S>И самое плохое — то, что на вашем языке неверные программы визуально не отличаются от верных. Вы усердно закладываете способы делать случайные ошибки, и способы комбинировать эти способы.

3.1) многовложенность ЕСЛИ <> ТО <> повышают вероятность семантической ошибки ака
S>Меня пугает изобилие условий перед тем, как выполнить действие 3. Малейшая ошибка — и аварийная защита так и не включится!

3.2) дублирование контекста (указание в выражении и в самом действии по этому выражению) ака
S>Вы хотите дать программисту возможность в любом месте поставить "вычисли это в контексте X", а я хочу не дать программисту указывать контекст руками. Ровно потому, что это удваивает шансы сделать ошибку, а мы хотим облегчить написание корректных программ.

Итак, попытаюсь ответить. Вы пишете

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

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

Теперь запишем тот самый мой вариант, но немного в более другой форме:

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

Сравните. По-моему, претензия 2) выглядит после этого несколько преувеличенной. Если программист-технолог не поймет мою запись, то не поймет и вашу, поскольку они практически идентичны с точностью до незначительных для понимания нюансов. Но все же, думаю, знакомому с процессом человеку нетрудно понять, что при написании программы руководствовались следующими соображениями: если температура превысила 100 градусов, то нужно ее понизить. Простейшее средство — снижение мощности, потому первым его и стараются применить. Если расчет модели покажет, что оно изначально не сработает, то следующее по затратам — отключение тена и включение охлаждения. Но, как известно (всякому технологу), оно действенно только либо если температура не выше 1000, либо если подача охладителя не приведет к выходу величины P*V за отметку 300. Поэтому, если и это не выполняется, то средств для нормализации температуры нет — остается аварийная защита.

Далее, по поводу 3.1). Ваши опасения насчет "Малейшая ошибка — и аварийная защита так и не включится!" вполне обоснованы. Но! Во-первых, это уже относится к области правильного проектирования программы, и в данном случае легко решается просто дописыванием в самом конце условия, которое будет всегда проверяться:

ЕСЛИ T > 100, ТО ВключитьАварийнуюЗащиту.

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

Остается 1) и 3.2). Насчет 1) — вы же тоже вводите контексты! Просто ограничиваете свободное обращение с ними. Потому остается претензия 3.2). Вот тут должен с вами согласиться — дублирование контекста выглядит "не очень". Я и сам пытался какие-то ограничения вводить. Но все сводилось к тому, что я не мог обосновать, почему в будущем не сможет возникнуть потребности в том, чтобы воспользоваться контекстом напрямую. Ну, например, почему не может возникнуть потребности проверить условие в контексте одного действия, а выполнить совсем другое. Ведь наверняка может быть что-нибудь типа

"ЕСЛИ ПРИ ПодатьОхладитель T > 1000 ", то "ВключитьАварийнуюЗащиту"

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

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

если [@C1 <exprs_1> ] < [@C2 <exprs_1>], то
    если [@C2 <exprs_1> ] > [@C2 <exprs_2>], то C2
иначе С1

(Кстати, как в вашем варианте оно запишется? Что-то не могу сообразить...)

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

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

S>Непонятно, можно ли делать несколько действий одновременно (и нужно ли)?

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

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

Да, теперь вижу, о чем AlexCab толковал в последнем посте (сразу этот момент не заметил).

S>Лично я всегда выступаю как адвокат пользователя, в нашем случае — программиста этих контроллеров.

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

_>Ничего подобного, во-первых, может быть программа, которая заставляет контроллер "действовать" только, когда что-то выходит за рамки. В остальных случая ничего делать не нужно. Во-вторых, может быть ситуация, когда у вас множество условий в программе, и то, что первая проверенная часть условий не запустила никакого действия просто означает, что запуск действия передается другой части условий. В вашем же случае с обязательным действием придется вводить фиктивное действие типа "ничего не делать".
У вас ведь декларативный стиль, в нём нет последовательностей действий/проверок: либо одно/несколько(одновременно) условий совпадают и происходит одно/несколько(одновременных) действий, либо не одно условие не совпадает и ничего не происходит.

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

_>>Ничего подобного, во-первых, может быть программа, которая заставляет контроллер "действовать" только, когда что-то выходит за рамки. В остальных случая ничего делать не нужно. Во-вторых, может быть ситуация, когда у вас множество условий в программе, и то, что первая проверенная часть условий не запустила никакого действия просто означает, что запуск действия передается другой части условий. В вашем же случае с обязательным действием придется вводить фиктивное действие типа "ничего не делать".
AC>У вас ведь декларативный стиль, в нём нет последовательностей действий/проверок: либо одно/несколько(одновременно) условий совпадают и происходит одно/несколько(одновременных) действий, либо не одно условие не совпадает и ничего не происходит.

Я вас опять не понимаю. В данном месте речи ни о какой последовательности не идет. Вот:

если "голоден", то "принять пищу"
если "мучает жажда", то "попить воды"

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

Если же вы хотели сделать замечание к моему

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

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

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

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

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

__>Теперь запишем тот самый мой вариант, но немного в более другой форме:

__>

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

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

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

Сможете сходу сказать, вычисляется ли T < 1000 в текущем контексте или нет? Даже если мы устраним неоднозначность путём расстановки скобок, то программы с принципиально разной семантикой всё ещё будут выглядеть слишком похожими.
А главный вопрос: чем ваша программа лучше моей? Вы ввели потенциальную непонятность и добавили многословности.

__>Остается 1) и 3.2). Насчет 1) — вы же тоже вводите контексты! Просто ограничиваете свободное обращение с ними.
Конечно. Я исключаю вероятность ошибки неверного смешения контекстов.
__>Потому остается претензия 3.2). Вот тут должен с вами согласиться — дублирование контекста выглядит "не очень". Я и сам пытался какие-то ограничения вводить. Но все сводилось к тому, что я не мог обосновать, почему в будущем не сможет возникнуть потребности в том, чтобы воспользоваться контекстом напрямую. Ну, например, почему не может возникнуть потребности проверить условие в контексте одного действия, а выполнить совсем другое.
В 99.9% такая ситуация — ошибка проектирования. "Если от водки тебя стошнит, то выпей коньяка".
__>Ведь наверняка может быть что-нибудь типа

__>

__>"ЕСЛИ ПРИ ПодатьОхладитель T > 1000 ", то "ВключитьАварийнуюЗащиту"
__>

Неплохой пример. Вот видите, какого прогресса можно достичь, если отвлечься от несущественных вопросов, и заняться делом?
Плохо то, что пример изолированный — вместо полной программы мы пытаемся перевести на наш язык какой-то отдельный фрагмент. Это всё равно, что пробовать перевести на русский слово "the".
Ну, то есть если у нас поблизости нет ветки, которая выбирает ПодатьОхладитель, то это явно косяк: какая нам разница, к каким результатам приведёт действие, если мы не собирались его выполнять?
Я бы ожидал примерно такого фрагмента:

"ЕСЛИ ПРИ ПодатьОхладитель T > 1000 ", то "ВключитьАварийнуюЗащиту", иначе "ПодатьОхладитель"

А такой фрагмент уже понятно, как записать на языке с неявными контекстами:

ПодатьОхладитель ЕСЛИТОГДА T > 1000, ИНАЧЕ ВключитьАварийнуюЗащиту

А по поводу 3.1. в моём варианте есть готовое решение "проверки последствий": благодаря тому, что оператор можно применять рекурсивно, можно обрамить всю программу единым пост-условием:
ВыбратьДействиеПоТехПроцессуПутёмАнализаМногоЧегоИСложного
ЕСЛИТОГДА T < TВзрыва AND P < PВзрыва
ИНАЧЕ ВключитьАварийнуюЗащиту

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

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

__>

__>если [@C1 <exprs_1> ] < [@C2 <exprs_1>], то
__>    если [@C2 <exprs_1> ] > [@C2 <exprs_2>], то C2
__>иначе С1
__>

__>(Кстати, как в вашем варианте оно запишется? Что-то не могу сообразить...)
Ок, отлично, мы движемся вперёд. Смотрите, у вас комбинация двух сценариев: сравнение выражения в разных контекстах и сравнение выражений в одном контексте. Перевод будем делать по частям:

если [@C2 <exprs_1> ] > [@C2 <exprs_2>], то C2 иначе C1 
=> 
  С2 ЕСЛИТОГДА <exprs_1> > <exprs_2> ИНАЧЕ С1

ИЗ C1, (С2 ЕСЛИТОГДА <exprs_1> > <exprs_2> ИНАЧЕ С1) ВЫБРАТЬ МИНИМИЗИРУЮЩЕЕ <exprs_1>

__>Это все правильные слова. Проблема в том, что я у меня нет большой базы примеров задач, которые придется решать с помощью этого языка. Потому-то я и "фантазирую", какие варианты "гипотетически" могут встретиться. В этом плане моя задача — создать простой язык, который в случае чего можно было бы легко расширить для решения проблем, которых я не предвидел. И главное — не заложить что-то слишком ограничительное, что в дальнейшем не позволит это сделать.
Всё строго наоборот. Если вы сделаете язык без возможности X, то потом её всегда можно будет добавить, если она нужна. Если вы сделаете язык с возможностью Y, которая окажется вредной, то потом вы задолбаетесь её убирать — ведь на неё уже будут заточены программы, и даже не все из них будут некорректны. Вот тот пример, который рассмотрен в самом начале этого поста — вы привели корректную программу со смешением контекстов, а я — некорректную. Когда вы поймёте, что ошибок типа моей встречаются сотни и захотите убрать возможность явного указания контекста операции, будет уже поздно.

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

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

Лично мне интуитивно кажется, что совмещение действий должно работать одним из двух способов:
1. Параллельное выполнение
2. Последовательное выполнение
Можно их свести к одному оператору "композиция с задержкой" — типа "инициировать открытие предохранительного клапана АТАКЖЕ ЧЕРЕЗ 200мс начать нагрев". Если у действий есть длительность, то помимо "start-to-start" потребуются варианты композиции "finish-to-start", "finish-to-finish".

К сожалению, у таких составных действий появляется лишняя степень свободы. Если раньше контекстов было, грубо говоря, два — до действия и после действия, то теперь есть промежуточные стадии. Если я описал действие "вскипятить" в терминах "включить_тэн АТАКЖЕ ЧЕРЕЗ 15мин отключить_тэн", то вычисление T "после действия" не даст мне понять, что в процессе могут быть достигнуты критические значения.
В принципе, можно расширить семантику операторов сравнения в со значений на функции — то есть когда мы говорим "вскипятить ЕСЛИТОГДА T <= 150", то мы имеем в виду "температура не должна превышать 150 в течение выполнения всего действия". Но тут есть ещё много граблей, и прежде чем лезть в эту область, хотелось лучше понять требования.

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

__>Неужели вы думаете, что я на другой стороне. Зачем бы мне тогда вообще было заморачиваться с удобством и гибкостью, и обсуждать здесь все это с вами?
Мне в какой-то момент показалось, что вы фанат лямбда-исчисления, и вас интересуют академические вещи типа построения непротиворечивой модели context-bound вычислений

Здравствуйте, Sinclair, Вы писали:
S>А такой фрагмент уже понятно, как записать на языке с неявными контекстами:
S>

S>ПодатьОхладитель ЕСЛИТОГДА T > 1000, ИНАЧЕ ВключитьАварийнуюЗащиту
S>

Опечатка:

  ПодатьОхладитель ЕСЛИТОГДА T <= 1000, ИНАЧЕ ВключитьАварийнуюЗащиту

_>>>Ничего подобного, во-первых, может быть программа, которая заставляет контроллер "действовать" только, когда что-то выходит за рамки. В остальных случая ничего делать не нужно. Во-вторых, может быть ситуация, когда у вас множество условий в программе, и то, что первая проверенная часть условий не запустила никакого действия просто означает, что запуск действия передается другой части условий. В вашем же случае с обязательным действием придется вводить фиктивное действие типа "ничего не делать".
AC>>У вас ведь декларативный стиль, в нём нет последовательностей действий/проверок: либо одно/несколько(одновременно) условий совпадают и происходит одно/несколько(одновременных) действий, либо не одно условие не совпадает и ничего не происходит.
__>Я вас опять не понимаю.
Это относится к выделенному, я подумал что вы хотите сделать что-то вроде:
1)"вычислить первую часть условия" -> "действие" ИНАЧЕ "ничего не делать" => 2)"вычислить вторую часть условия" -> "действие" ИНАЧЕ "ничего не делать"
Т.е. сначала проверяется первое условие и выполняется "действие" или "ничего не делать", затем если в предыдущем условии было выполнено "ничего не делать", то проверяется второе условие и выполняется "действие" либо "ничего не делать". Таким образом получается последовательность из "ничего не делать" и "действие".
Я не правильно понял? Как вы собирались применять действие "ничего не делать"?
__>Если же вы хотели сделать замечание к моему
__>

__>если есть два условия, которые выполняются одновременно и должны запустить различные действия, то эти действия будут запущены тоже одновременно в том порядке, в котором были проверены условия.

__>в котором речь идет о порядке проверки условий, то да, согласен, порядок появляется. Но, во-первых, как мне кажется, он здесь в довольно невинной форме — лишь для того, чтобы упорядочить одновременно активируемые действия (похожий порядок, если не ошибаюсь, есть и в Хаскеле. Он определяет, какой клоз будет выбран, если есть несколько одновременно подходящих вариантов), а во-вторых, раз уж вводятся вычисления в контексте, то как я уже показывал ранее, в любом случае нужно будет в спецификации языка указывать, в каком порядке будут осуществляться вычисления выражений (в аппликативном или нормальном). Так что порядок проврки условий по сравнению с этим сама невинность.
Думаю "порядок проверок/действий", в вашем случае, это абсолютно лишняя сущность, не привносящая ничего кроме дополнительной сложности.

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

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

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

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

__>>Теперь запишем тот самый мой вариант, но немного в более другой форме:

__>>

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

__>>Сравните. По-моему, претензия 2) выглядит после этого несколько преувеличенной.
S>Не вполне. Вот смотрите — у меня искусственно разнесены условия для проверки "до" действия и для проверки "после" действия. Это не случайно — я хочу гарантировать отсутствие ошибок. Вам кажется, что ваша программа очевидна? Давайте внесём мелкое косметическое изменение, переставив аргументы коммутативного оператора:
S>

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

S>Сможете сходу сказать, вычисляется ли T < 1000 в текущем контексте или нет? Даже если мы устраним неоднозначность путём расстановки скобок, то программы с принципиально разной семантикой всё ещё будут выглядеть слишком похожими.

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

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

В вашем примере с переставленным порядком это будет выглядеть:

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

Разница между ними сразу бросается в глаза.

S>А главный вопрос: чем ваша программа лучше моей?

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

S>Вы ввели потенциальную непонятность и добавили многословности.

"Бабушка надвое сказала". У меня одна и та же легко объясняемая контрукция всюду: [@<action> <expression> @] (любому человеку легко объяснить, что эту конструкцию надо просто читать как "значение выражения, если бы действие <action> произошло"). Фактически, ничего нового. В вашем же случае добавляются по меньшей мере две принципиально новые конструкции: одна с ЕСЛИТОГДА, вторая с ВЫБРАТЬ_ИЗ <критерий>, с довольно непривычными для восприятия семантиками (это надо быть тестером или иметь опыт работы с SQL, чтобы сразу вникнуть в суть).

__>>наверняка может быть что-нибудь типа

__>>

__>>"ЕСЛИ ПРИ ПодатьОхладитель T > 1000 ", то "ВключитьАварийнуюЗащиту"
__>>

S>Неплохой пример. Вот видите, какого прогресса можно достичь, если отвлечься от несущественных вопросов, и заняться делом?
S>Плохо то, что пример изолированный — вместо полной программы мы пытаемся перевести на наш язык какой-то отдельный фрагмент. Это всё равно, что пробовать перевести на русский слово "the".
S>Ну, то есть если у нас поблизости нет ветки, которая выбирает ПодатьОхладитель, то это явно косяк: какая нам разница, к каким результатам приведёт действие, если мы не собирались его выполнять?
S>Я бы ожидал примерно такого фрагмента:

S>

S>"ЕСЛИ ПРИ ПодатьОхладитель T > 1000 ", ТО "ВключитьАварийнуюЗащиту", иначе "ПодатьОхладитель"
S>

S>А такой фрагмент уже понятно, как записать на языке с неявными контекстами:
S>

S> ПодатьОхладитель ЕСЛИТОГДА T <= 1000, ИНАЧЕ ВключитьАварийнуюЗащиту
S>

Это вы додумали "в свою пользу". А теперь я в свою:

  "ЕСЛИ ПРИ ПодатьОхладитель T > 1000 ", ТО "УвеличитьОбъемЦилиндраДоМаксимального"

Здесь смысл таков — ПодатьОхладитель — это виртуальный тест, который проверят, можно ли будет (в случае надобности) с помощью подачи охладителя достичь нормальной температуры. И если нет, то запускается действие УвеличитьОбъемЦилиндраДоМаксимального, заранее гарантирующее, что подача охладителя в случае надобности будет действовать (понижать температуру до нужной).

S>А по поводу 3.1. в моём варианте есть готовое решение "проверки последствий": благодаря тому, что оператор можно применять рекурсивно, можно обрамить всю программу единым пост-условием:
S>ВыбратьДействиеПоТехПроцессуПутёмАнализаМногоЧегоИСложного
S> ЕСЛИТОГДА T < TВзрыва AND P < PВзрыва
S> ИНАЧЕ ВключитьАварийнуюЗащиту

В моем случае все было гораздо проще — просто в конце программы записывается:

ЕСЛИ <условие критической ситуации> ТО ВключитьАварийнуюЗащиту

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

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

__>>

__>>если [@C1 <exprs_1> ] < [@C2 <exprs_1>], то
__>>    если [@C2 <exprs_1> ] > [@C2 <exprs_2>], то C2
__>>иначе С1
__>>

__>>(Кстати, как в вашем варианте оно запишется? Что-то не могу сообразить...)
S>Ок, отлично, мы движемся вперёд. Смотрите, у вас комбинация двух сценариев: сравнение выражения в разных контекстах и сравнение выражений в одном контексте. Перевод будем делать по частям:
S>

S>если [@C2 <exprs_1> ] > [@C2 <exprs_2>], то C2 иначе C1 
S>=> 
S>  С2 ЕСЛИТОГДА <exprs_1> > <exprs_2> ИНАЧЕ С1
S>

S>

S>ИЗ C1, (С2 ЕСЛИТОГДА <exprs_1> > <exprs_2> ИНАЧЕ С1) ВЫБРАТЬ МИНИМИЗИРУЮЩЕЕ <exprs_1> 
S>

Разве семантика конструкции С2 ЕСЛИТОГДА <exprs_1> > <exprs_2> ИНАЧЕ С1 не является "запустить действие С2 если в его контексте выполнено <exprs_1> > <exprs_2>, иначе запустить действие С1. Или у вас только осуществляется вычисление действия, а запуск происходит в самом-самом конце?
Но тогда как быть с одновременным выбором нескольких действий? Что-то я перестал понимать, как у вас это работает...

__>>Это все правильные слова. Проблема в том, что я у меня нет большой базы примеров задач, которые придется решать с помощью этого языка. Потому-то я и "фантазирую", какие варианты "гипотетически" могут встретиться. В этом плане моя задача — создать простой язык, который в случае чего можно было бы легко расширить для решения проблем, которых я не предвидел. И главное — не заложить что-то слишком ограничительное, что в дальнейшем не позволит это сделать.
S>Всё строго наоборот. Если вы сделаете язык без возможности X, то потом её всегда можно будет добавить, если она нужна. Если вы сделаете язык с возможностью Y, которая окажется вредной, то потом вы задолбаетесь её убирать — ведь на неё уже будут заточены программы, и даже не все из них будут некорректны. Вот тот пример, который рассмотрен в самом начале этого поста — вы привели корректную программу со смешением контекстов, а я — некорректную. Когда вы поймёте, что ошибок типа моей встречаются сотни и захотите убрать возможность явного указания контекста операции, будет уже поздно.

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

__>>Чтобы в дальнейшем не возникало вопросов — да, в описании языка будет сказано, что если есть два условия, которые выполняются одновременно и должны запустить различные действия, то эти действия будут запущены тоже одновременно в том порядке, в котором были проверены условия.
S>Вот это — резкое усложнение. Вы же понимаете, что это сразу перечеркивает все наши предыдущие усилия по внятному заданию предикатов?

Совершенно неожиданное для меня заявление. С чего бы это на что-то влияло???

Или вы имеете в виду перечеркивание вашего варианта?

S>Банально, мы можем иметь программу, которая в первой части проверяет, можно ли поднять температуру, предполагая неизменное давление. А во второй части проверяет, можно ли поднять давление, предполагая неизменную температуру. И в итоге выполняет оба действия одновременно, взрывая установку.

У меня с этим не вижу никаких проблем: условия независимы друг от друга и ничего не "предполагают" — берут текущие показания датчиков, текущие предсказания модели, и активируют или нет действия.

ЕСЛИ (T < 50) AND [@ВключитьПодогрев P < 300], ТО ВключитьПодогрев
ЕСЛИ (P < 100)AND [@УменьшитьОбъемДоМинимального T < 1000]), ТО УменьшитьОбъемДоМинимального

Если, например, исходные Т = 20, P = 50, то первое условие включит подогрев. Повысится температура и автоматом давление, например, станут Т = 70, P = 90. Тогда во втором условии при проверке [@УменьшитьОбъемДоМинимального T < 1000] будет выполнено моделирование температуры газа, исходя из начальных условий Т = 70, P = 90, и действия "уменьшение объема".

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

Да, была такая мысль. Если не слишком сложным окажется, попытаюсь ее реализовать.

S>Лично мне интуитивно кажется, что совмещение действий должно работать одним из двух способов:
S>1. Параллельное выполнение
S>2. Последовательное выполнение
S>Можно их свести к одному оператору "композиция с задержкой" — типа "инициировать открытие предохранительного клапана АТАКЖЕ ЧЕРЕЗ 200мс начать нагрев". Если у действий есть длительность, то помимо "start-to-start" потребуются варианты композиции "finish-to-start", "finish-to-finish".

Никакого параллелизма. Только последовательное! На обычных компах параллелизм == геморрой, а вы хотите на контроллерах, да еще и со школьниками-программистами.

S>К сожалению, у таких составных действий появляется лишняя степень свободы. Если раньше контекстов было, грубо говоря, два — до действия и после действия, то теперь есть промежуточные стадии. Если я описал действие "вскипятить" в терминах "включить_тэн АТАКЖЕ ЧЕРЕЗ 15мин отключить_тэн", то вычисление T "после действия" не даст мне понять, что в процессе могут быть достигнуты критические значения.
S>В принципе, можно расширить семантику операторов сравнения в со значений на функции — то есть когда мы говорим "вскипятить ЕСЛИТОГДА T <= 150", то мы имеем в виду "температура не должна превышать 150 в течение выполнения всего действия". Но тут есть ещё много граблей, и прежде чем лезть в эту область, хотелось лучше понять требования.

Не хотел, конечно, в это влазить, но видимо придется...
Итак, наверное можно считать так: подгорев газа, подача охладителя осуществляется по заранее составленному технологом циклически повторяющемуся временному графику, в котором прописано:
— момент включения тена, величина мощности, длительность
— момент подачи охладителя, величина мощности охладителя, длительность.

Переходы с одного состояния на другое "с включено на выключено и наоборот" называются событиями и каждое в отдельности идентифицируются. Например, если предполагается в цикле три раза включать нагрев, то будет три события вклчения, и три события выключения. Каждое из них будет иметь идентификатор наподобие HeatOn_1, HeatOn_2, HeatOn_3 — события включения нагрева, HeatOff_1, HeatOff_2, HeatOff_3 — события выключения нагрева.
Аналогично для охлаждения: CoolOn_1, CoolOn_2, CoolOn_3, CoolOff_1, CoolOff_2, CoolOff_3.

Все основные действия контроллера связаны с "редактированием расписания" — с изменением длительностей и величин мощностей охладителя и тена в нем. Например,
действие 1 = сократить до минимума длительность охлаждения, связанного с событием СоolOn_1 и неизрасходованное на охлаждение время добавить в длительность охлаждения, отвечающего событию CoolOn_2.

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

ЕСЛИ IsActual[СоolOn_1] AND [Weight < 1кг], ТО
ЕСЛИ [@действие_1 GetProcessMaxPressure[CoolOn_2] < 300], ТО действие_1

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

В общем, как-то так. Не знаю, насколько понятно...

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

__>>Неужели вы думаете, что я на другой стороне. Зачем бы мне тогда вообще было заморачиваться с удобством и гибкостью, и обсуждать здесь все это с вами?
S>Мне в какой-то момент показалось, что вы фанат лямбда-исчисления, и вас интересуют академические вещи типа построения непротиворечивой модели context-bound вычислений

Меня интересует, как сделать язык более простым для понимания. Декларативные языки в исходном виде как раз таковы — их понимание проще из-за того, что практически нет зависимости от порядка вычисления выражений (не нужно заморачиваться понятием control flow). Потому и завел речь, как ввести контекст и остаться в русле декларативности (ака, как ввести контекст и при этом все так же не напрягать пользователя заучиванием нюансов, связанных с порядком выполнения вычислений).

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

_>>>>первая проверенная часть условий не запустила никакого действия просто означает, что запуск действия передается другой части условий. В вашем же случае с обязательным действием придется вводить фиктивное действие типа "ничего не делать".
AC>>>У вас ведь декларативный стиль, в нём нет последовательностей действий/проверок: либо одно/несколько(одновременно) условий совпадают и происходит одно/несколько(одновременных) действий, либо не одно условие не совпадает и ничего не происходит.
__>>Я вас опять не понимаю.
AC>Это относится к выделенному, я подумал что вы хотите сделать что-то вроде:
AC>1)"вычислить первую часть условия" -> "действие" ИНАЧЕ "ничего не делать" => 2)"вычислить вторую часть условия" -> "действие" ИНАЧЕ "ничего не делать"
AC>Т.е. сначала проверяется первое условие и выполняется "действие" или "ничего не делать", затем если в предыдущем условии было выполнено "ничего не делать", то проверяется второе условие и выполняется "действие" либо "ничего не делать". Таким образом получается последовательность из "ничего не делать" и "действие".
AC>Я не правильно понял? Как вы собирались применять действие "ничего не делать"?

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

если "голоден", то "принять пищу"
если "мучает жажда", то "попить воды"

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

__>>Если же вы хотели сделать замечание к моему
__>>

__>>если есть два условия, которые выполняются одновременно и должны запустить различные действия, то эти действия будут запущены тоже одновременно в том порядке, в котором были проверены условия.

__>>в котором речь идет о порядке проверки условий, то да, согласен, порядок появляется. Но, во-первых, как мне кажется, он здесь в довольно невинной форме — лишь для того, чтобы упорядочить одновременно активируемые действия (похожий порядок, если не ошибаюсь, есть и в Хаскеле. Он определяет, какой клоз будет выбран, если есть несколько одновременно подходящих вариантов), а во-вторых, раз уж вводятся вычисления в контексте, то как я уже показывал ранее, в любом случае нужно будет в спецификации языка указывать, в каком порядке будут осуществляться вычисления выражений (в аппликативном или нормальном). Так что порядок проврки условий по сравнению с этим сама невинность.
AC>Думаю "порядок проверок/действий", в вашем случае, это абсолютно лишняя сущность, не привносящая ничего кроме дополнительной сложности.

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

__>Да, вы поняли неправильно.
Ok.
AC>>Думаю "порядок проверок/действий", в вашем случае, это абсолютно лишняя сущность, не привносящая ничего кроме дополнительной сложности.
__>Как же вы в таком случае сможете гарантировать порядок, в котором будет приниматься пища и выпиваться вода, если одновременно и голоден, и мучает жажда? Только не расстраивайте — не говорите, что это неважно.
Почему же не возможно, разве вы никогда не запивали, например хлеб молоком?

Но если серьёзно — порядок определяется условием, например следующий код по мере роста температуры будет выполнять по порядку(т.е. не одновременно) указанные действия:

on_cooler if temperature > 100
warning if temperature > 200
alarm if temperature > 300

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

__>>Да, вы поняли неправильно.
AC>Ok.
AC>>>Думаю "порядок проверок/действий", в вашем случае, это абсолютно лишняя сущность, не привносящая ничего кроме дополнительной сложности.
__>>Как же вы в таком случае сможете гарантировать порядок, в котором будет приниматься пища и выпиваться вода, если одновременно и голоден, и мучает жажда? Только не расстраивайте — не говорите, что это неважно.
AC>Почему же не возможно, разве вы никогда не запивали, например хлеб молоком?

Читайте внимательнее сообщения (выделил жирным и подчеркнул).

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

AC>on_cooler if temperature > 100
AC>warning if temperature > 200
AC>alarm if temperature > 300
AC>

Вы о каком порядке говорите? Я о порядке, в котором приводятся в исполнение действия, условия наступления которых срабатывают в один и тот же момент.

Например, в вашем примере, если будет сразу Т = 100000, как задать, чтобы в этом случае в логе подач команд прописалось:
12:23:21 cooler on
12:23:21 warning on
12:23:21 alarm on
именно в таком порядке, и никаком ином? И опять же, не говорите, что это неважно, иначе не имеет смысла продолжать диалог.

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

AC>>on_cooler if temperature > 100
AC>>warning if temperature > 200
AC>>alarm if temperature > 300
AC>>

__>Вы о каком порядке говорите? Я о порядке, в котором приводятся в исполнение действия, условия наступления которых срабатывают в один и тот же момент.
Я говорю о том как сделать чтобы действия выполнялись в определённом порядке, когда это нужно.
__>Например, в вашем примере, если будет сразу Т = 100000, как задать, чтобы в этом случае в логе подач команд прописалось:
__>12:23:21 cooler on
__>12:23:21 warning on
__>12:23:21 alarm on
__>именно в таком порядке, и никаком ином? И опять же, не говорите, что это неважно, иначе не имеет смысла продолжать диалог.
1)Сделать так как написал пользователь — забота вычислительной модели(это собственно скомпилирования программа которая будет работать в МК). Например в случае если температура резко скакнула от 10 до 100000 программа всё равно должна выполнится так как будто температура поднималась плавно.
2)Я действительно считаю что, в контексте вашей задачи, это не важно, и вероятно будет не востребовано. Но даже если и будет эту фичю легко добавить, например введением приоритетов действий.

PS: Мне становится скучно

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

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

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

AC>>>on_cooler if temperature > 100
AC>>>warning if temperature > 200
AC>>>alarm if temperature > 300
AC>>>

__>>Вы о каком порядке говорите? Я о порядке, в котором приводятся в исполнение действия, условия наступления которых срабатывают в один и тот же момент.
AC>Я говорю о том как сделать чтобы действия выполнялись в определённом порядке, когда это нужно.
__>>Например, в вашем примере, если будет сразу Т = 100000, как задать, чтобы в этом случае в логе подач команд прописалось:
__>>12:23:21 cooler on
__>>12:23:21 warning on
__>>12:23:21 alarm on
__>>именно в таком порядке, и никаком ином? И опять же, не говорите, что это неважно, иначе не имеет смысла продолжать диалог.
AC>1)Сделать так как написал пользователь — забота вычислительной модели(это собственно скомпилирования программа которая будет работать в МК). Например в случае если температура резко скакнула от 10 до 100000 программа всё равно должна выполнится так как будто температура поднималась плавно.
AC>2)Я действительно считаю что, в контексте вашей задачи, это не важно, и вероятно будет не востребовано. Но даже если и будет эту фичю легко добавить, например введением приоритетов действий.

Ок. Дальше можно не продолжать. Извините, но такое ощущение, что вы очень далеки от реального программирования.

AC>PS: Мне становится скучно

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

Мне тоже скучно выслушивать ваши предложения о "сфреических конях в вакууме". Потому давайте все же не будем больше утруждать друг друга общением.

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

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

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

__>В вашем примере с переставленным порядком это будет выглядеть:

__>

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

__>Разница между ними сразу бросается в глаза.
Не могу с вами согласиться. Цитирую:

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

Показываю конкретный пример:

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

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

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

S>>Вы ввели потенциальную непонятность и добавили многословности.

__>"Бабушка надвое сказала". У меня одна и та же легко объясняемая контрукция всюду: [@<action> <expression> @] (любому человеку легко объяснить, что эту конструкцию надо просто читать как "значение выражения, если бы действие <action> произошло"). Фактически, ничего нового. В вашем же случае добавляются по меньшей мере две принципиально новые конструкции: одна с ЕСЛИТОГДА, вторая с ВЫБРАТЬ_ИЗ <критерий>, с довольно непривычными для восприятия семантиками (это надо быть тестером или иметь опыт работы с SQL, чтобы сразу вникнуть в суть).
Я уже говорил — кто-то из нас опирается на неверные предположения. Вы считаете, что ваша целевая аудитория легко парсит в уме сложные выражения, и концепция "вычислить выражение в предположении, что всё будет не так как сейчас" не свернёт ей мозг. Я интуитивно ожидаю, что целевая аудитория опыта программирования на птичьих языках типа C++ не имеет, поэтому ей проще объяснить конкретные концепции, чем математическую абстракцию.

Странно, что вы не верите в то, что мой синтаксис лучше — несмотря на наличие наглядных примеров. Вот вам ещё пример того, как ваш синтаксис позволяет писать заведомо некорректные программы:

 ЕСЛИ Т > 100, ТО ЕСЛИ  [@CнизитьМощностьТэна1 Т < 100 @], ТО CнизитьМощностьТэна2

Такие ошибки очень легко допустить в реальной программе. А всё оттого что вы настаиваете на совершенно ненужной возможности — явно указывать контекст для вычисления выражения.

__>Это вы додумали "в свою пользу". А теперь я в свою:

__>

__>  "ЕСЛИ ПРИ ПодатьОхладитель T > 1000 ", ТО "УвеличитьОбъемЦилиндраДоМаксимального"
__>

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

S>>А по поводу 3.1. в моём варианте есть готовое решение "проверки последствий": благодаря тому, что оператор можно применять рекурсивно, можно обрамить всю программу единым пост-условием:
S>>ВыбратьДействиеПоТехПроцессуПутёмАнализаМногоЧегоИСложного
S>> ЕСЛИТОГДА T < TВзрыва AND P < PВзрыва
S>> ИНАЧЕ ВключитьАварийнуюЗащиту

__>В моем случае все было гораздо проще — просто в конце программы записывается:

__>ЕСЛИ <условие критической ситуации> ТО ВключитьАварийнуюЗащиту
А в каком контексте вычисляется это ваше "<условие критической ситуации>"? Если в текущем — то в моём синтаксисе оно пишется строго также. Но вы же меня уверяли, что вам нужно включать защиту не тогда, когда уже всё взорвалось, а когда вы видите, что ни одно из предусмотренных действий не сможет предотвратить выход за контрольные значения. В вашем синтаксисе это как запишется? С учётом того, что в программе идёт выбор из, скажем, полусотни различных действий.

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

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

__>>>

__>>>если [@C1 <exprs_1> ] < [@C2 <exprs_1>], то
__>>>    если [@C2 <exprs_1> ] > [@C2 <exprs_2>], то C2
__>>>иначе С1
__>>>

__>>>(Кстати, как в вашем варианте оно запишется? Что-то не могу сообразить...)
S>>Ок, отлично, мы движемся вперёд. Смотрите, у вас комбинация двух сценариев: сравнение выражения в разных контекстах и сравнение выражений в одном контексте. Перевод будем делать по частям:
S>>

S>>если [@C2 <exprs_1> ] > [@C2 <exprs_2>], то C2 иначе C1 
S>>=> 
S>>  С2 ЕСЛИТОГДА <exprs_1> > <exprs_2> ИНАЧЕ С1
S>>

S>>

S>>ИЗ C1, (С2 ЕСЛИТОГДА <exprs_1> > <exprs_2> ИНАЧЕ С1) ВЫБРАТЬ МИНИМИЗИРУЮЩЕЕ <exprs_1> 
S>>

__>Разве семантика конструкции С2 ЕСЛИТОГДА <exprs_1> > <exprs_2> ИНАЧЕ С1 не является "запустить действие С2 если в его контексте выполнено <exprs_1> > <exprs_2>, иначе запустить действие С1. Или у вас только осуществляется вычисление действия, а запуск происходит в самом-самом конце?
Конечно же сначала происходит выбор действия, а реальный запуск происходит только по окончанию вычисления всех операторов. Разве это не очевидно? Без этого не получится каскадировать операторы.

__>Но тогда как быть с одновременным выбором нескольких действий? Что-то я перестал понимать, как у вас это работает...
Ну, у меня это "работает" очень просто: программа состоит из блоков; каждый блок анализируется и из него выбирается либо 0 либо 1 действие. Выбранные действия из каждого блока запускаются.
Предполагается, что "запуск" анализа происходит по какому-то расписанию — скажем, раз в минуту.

__>Если вы изначально заложите в язык "неудачный скелет", то даже если вы в дальнейшем расширите его "крыльями", летать он не сможет, поскольку одно будет мешать другому (тяжелый скелет не даст подняться).
Я не понимаю, о чём вы говорите. Расширять язык всегда проще, чем сужать.

__>Совершенно неожиданное для меня заявление. С чего бы это на что-то влияло???

Или вы имеете в виду перечеркивание вашего варианта?
Я же ниже написал, "с чего бы" это будет на что-то влиять.
S>>Банально, мы можем иметь программу, которая в первой части проверяет, можно ли поднять температуру, предполагая неизменное давление. А во второй части проверяет, можно ли поднять давление, предполагая неизменную температуру. И в итоге выполняет оба действия одновременно, взрывая установку.

__>У меня с этим не вижу никаких проблем: условия независимы друг от друга и ничего не "предполагают" — берут текущие показания датчиков, текущие предсказания модели, и активируют или нет действия.

__>ЕСЛИ (T < 50) AND [@ВключитьПодогрев P < 300], ТО ВключитьПодогрев
__>ЕСЛИ (P < 100)AND [@УменьшитьОбъемДоМинимального T < 1000]), ТО УменьшитьОбъемДоМинимального

__>Если, например, исходные Т = 20, P = 50, то первое условие включит подогрев. Повысится температура и автоматом давление, например, станут Т = 70, P = 90. Тогда во втором условии при проверке [@УменьшитьОбъемДоМинимального T < 1000] будет выполнено моделирование температуры газа, исходя из начальных условий Т = 70, P = 90, и действия "уменьшение объема".
Вы понимаете, что "Повысится температура" минут, скажем, через десять после "ВключитьПодогрев", да?
А контроллер перейдёт к следующей строчке через пару сотен тактов.
Почему вы думаете, что второе условие будет вычисляться с изменёнными значениями параметров?

__>Никакого параллелизма. Только последовательное! На обычных компах параллелизм == геморрой, а вы хотите на контроллерах, да еще и со школьниками-программистами.
Про школьников я слышу в первый раз. Это сильно меняет дело.

S>>К сожалению, у таких составных действий появляется лишняя степень свободы. Если раньше контекстов было, грубо говоря, два — до действия и после действия, то теперь есть промежуточные стадии. Если я описал действие "вскипятить" в терминах "включить_тэн АТАКЖЕ ЧЕРЕЗ 15мин отключить_тэн", то вычисление T "после действия" не даст мне понять, что в процессе могут быть достигнуты критические значения.
S>>В принципе, можно расширить семантику операторов сравнения в со значений на функции — то есть когда мы говорим "вскипятить ЕСЛИТОГДА T <= 150", то мы имеем в виду "температура не должна превышать 150 в течение выполнения всего действия". Но тут есть ещё много граблей, и прежде чем лезть в эту область, хотелось лучше понять требования.

__>Не хотел, конечно, в это влазить, но видимо придется...
__>Итак, наверное можно считать так: подгорев газа, подача охладителя осуществляется по заранее составленному технологом циклически повторяющемуся временному графику, в котором прописано:
__>- момент включения тена, величина мощности, длительность
__>- момент подачи охладителя, величина мощности охладителя, длительность.

__>Переходы с одного состояния на другое "с включено на выключено и наоборот" называются событиями и каждое в отдельности идентифицируются. Например, если предполагается в цикле три раза включать нагрев, то будет три события вклчения, и три события выключения. Каждое из них будет иметь идентификатор наподобие HeatOn_1, HeatOn_2, HeatOn_3 — события включения нагрева, HeatOff_1, HeatOff_2, HeatOff_3 — события выключения нагрева.
__>Аналогично для охлаждения: CoolOn_1, CoolOn_2, CoolOn_3, CoolOff_1, CoolOff_2, CoolOff_3.

__> Все основные действия контроллера связаны с "редактированием расписания" — с изменением длительностей и величин мощностей охладителя и тена в нем. Например,
__>действие 1 = сократить до минимума длительность охлаждения, связанного с событием СоolOn_1 и неизрасходованное на охлаждение время добавить в длительность охлаждения, отвечающего событию CoolOn_2.

__>У технолога есть доступ к функциям, позволяющим по идентификатору события получать различную информацию, например,

__>ЕСЛИ IsActual[СоolOn_1] AND [Weight < 1кг], ТО
__> ЕСЛИ [@действие_1 GetProcessMaxPressure[CoolOn_2] < 300], ТО действие_1

__>По смыслу, если в данный момент идет охлаждение вызванное событием СоolOn_1, и нагрузка на поршень невелика, то можно сэкономить, выключив охлаждение раньше времени и перенеся оставшееся время следующему по расписанию включению охлаждения при условии, что это не вызовет выход процесса за пределы 300 на интервале от текущего момента до момента наступления события CoolOn_2.

__>В общем, как-то так. Не знаю, насколько понятно...
Пока понятно плохо. Надо ещё примеров

__>Меня интересует, как сделать язык более простым для понимания. Декларативные языки в исходном виде как раз таковы — их понимание проще из-за того, что практически нет зависимости от порядка вычисления выражений (не нужно заморачиваться понятием control flow).
Ну, в этом месте вы противоречите сами себе — выше по тексту вы рассказывали, что "следующие" выражения вычисляются после выполнения действий, заданных предыдущими выражениями. Тут никакой декларативности нет.

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

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

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

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

S>Показываю конкретный пример:

S>     ЕСЛИ [@ОтключитьТэнИПодатьОхладитель  P*V < 300 ИЛИ Т < 1000 @] , ТО ОтключитьТэнИПодатьОхладитель,

S>     ЕСЛИ [@ОтключитьТэнИПодатьОхладитель  P*V < 300 @] ИЛИ Т < 1000, ТО ОтключитьТэнИПодатьОхладитель,

S>И это мы рассматриваем очень-очень простой пример. Если чуть усложнить предикат, то разобраться, какая его часть в каком контексте вычисляется будет ещё сложнее.

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

S>>>Вы ввели потенциальную непонятность и добавили многословности.

__>>"Бабушка надвое сказала". У меня одна и та же легко объясняемая контрукция всюду: [@<action> <expression> @] (любому человеку легко объяснить, что эту конструкцию надо просто читать как "значение выражения, если бы действие <action> произошло"). Фактически, ничего нового. В вашем же случае добавляются по меньшей мере две принципиально новые конструкции: одна с ЕСЛИТОГДА, вторая с ВЫБРАТЬ_ИЗ <критерий>, с довольно непривычными для восприятия семантиками (это надо быть тестером или иметь опыт работы с SQL, чтобы сразу вникнуть в суть).
S>Я уже говорил — кто-то из нас опирается на неверные предположения. Вы считаете, что ваша целевая аудитория легко парсит в уме сложные выражения, и концепция "вычислить выражение в предположении, что всё будет не так как сейчас" не свернёт ей мозг.

Кхм...То есть, понять, что конструкция [@включить_тен P*V @] означат "произведение давления на объем при включенном тене" — это свернуть мозг? Хоть аудитория у меня и без высшего образования, но, думаю, не умственно отсталые.

S>Странно, что вы не верите в то, что мой синтаксис лучше — несмотря на наличие наглядных примеров. Вот вам ещё пример того, как ваш синтаксис позволяет писать заведомо некорректные программы:
S>

S> ЕСЛИ Т > 100, ТО ЕСЛИ  [@CнизитьМощностьТэна1 Т < 100 @], ТО CнизитьМощностьТэна2
S>

S>Такие ошибки очень легко допустить в реальной программе. А всё оттого что вы настаиваете на совершенно ненужной возможности — явно указывать контекст для вычисления выражения.

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

__>>Это вы додумали "в свою пользу". А теперь я в свою:

__>>

__>>  "ЕСЛИ ПРИ ПодатьОхладитель T > 1000 ", ТО "УвеличитьОбъемЦилиндраДоМаксимального"
__>>

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

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

S>>>А по поводу 3.1. в моём варианте есть готовое решение "проверки последствий": благодаря тому, что оператор можно применять рекурсивно, можно обрамить всю программу единым пост-условием:
S>>>ВыбратьДействиеПоТехПроцессуПутёмАнализаМногоЧегоИСложного
S>>> ЕСЛИТОГДА T < TВзрыва AND P < PВзрыва
S>>> ИНАЧЕ ВключитьАварийнуюЗащиту

__>>В моем случае все было гораздо проще — просто в конце программы записывается:

__>>ЕСЛИ <условие критической ситуации> ТО ВключитьАварийнуюЗащиту
S>А в каком контексте вычисляется это ваше "<условие критической ситуации>"? Если в текущем — то в моём синтаксисе оно пишется строго также. Но вы же меня уверяли, что вам нужно включать защиту не тогда, когда уже всё взорвалось, а когда вы видите, что ни одно из предусмотренных действий не сможет предотвратить выход за контрольные значения. В вашем синтаксисе это как запишется? С учётом того, что в программе идёт выбор из, скажем, полусотни различных действий.

А-аа, теперь понял, о чем вы. Да, тогда у меня одной глобальной проверки, упреждающей критические последствия выполнения выбранного действия, сделать нельзя будет. Можно будет определить это одним условием, типа L = <проверка на некритичность параметров>, а после в каждой ветке, способной запустить действие <action> вставлять в конце, перед запуском, условие:

... ЕСЛИ [@<action> L@], ТО <action>

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

S>Ну, у меня это "работает" очень просто: программа состоит из блоков; каждый блок анализируется и из него выбирается либо 0 либо 1 действие. Выбранные действия из каждого блока запускаются.

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

Возвращаясь еще раз к
__>>>>

__>>>>если [@C1 <exprs_1> ] < [@C2 <exprs_1>], то
__>>>>    если [@C2 <exprs_1> ] > [@C2 <exprs_2>], то C2
__>>>>иначе С1
__>>>>

__>>>>(Кстати, как в вашем варианте оно запишется? Что-то не могу сообразить...)

S>>>

S>>>ИЗ C1, (С2 ЕСЛИТОГДА <exprs_1> > <exprs_2> ИНАЧЕ С1) ВЫБРАТЬ МИНИМИЗИРУЮЩЕЕ <exprs_1> 
S>>>

Вам не кажется, что последняя запись очень "технична" — ее сложно перевести на человеческий язык. Добавьте сюда еще случай, когда у вас будет несколько вложенных ЕСЛИ, тогда у вас пойдут вложенные ВЫБРАТЬ МИНИМИЗИРУЮЩЕЕ — читабельность стремится к нулю. К тому же, как записывать сразу такие конструкции, не переводя их подобно тому, как вы делали выше с моих, мне трудно представить. Например, как просто на вашем языке можно записать это:

если [@C1 <exprs_1> ] < [@C2 <exprs_1>], то
    если [@C2 <exprs_1> ] > [@C2 <exprs_2>], то 
        если [@C2 <exprs_1> ] < [@C3 <exprs_1>], то C2,
        иначе С3
    иначе С1
иначе С0

?

__>>Если вы изначально заложите в язык "неудачный скелет", то даже если вы в дальнейшем расширите его "крыльями", летать он не сможет, поскольку одно будет мешать другому (тяжелый скелет не даст подняться).
S>Я не понимаю, о чём вы говорите. Расширять язык всегда проще, чем сужать.

Ну что ж непонятного. Представьте — вы Бог и создаете животное. Вы говорите, пока хочу, чтобы оно было очень сильным и неуязвимым, а потом, если будет надо, добавим "фич". И создаете слона. А потом вам захотелось добавить фичу "умеет летать". С вашей позиции это звучит так: "подумаешь, проблемы — просто расширим его за счет добавления крыльев". На деле же оказывается, что это принципиально несовместимые "фичи", а потому надо либо заново "пересоздавать" животное, либо отказаться от "полетов".

__>>Никакого параллелизма. Только последовательное! На обычных компах параллелизм == геморрой, а вы хотите на контроллерах, да еще и со школьниками-программистами.
S>Про школьников я слышу в первый раз. Это сильно меняет дело.

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

__>>Не хотел, конечно, в это влазить, но видимо придется...
__>>Итак, наверное можно считать так: подгорев газа, подача охладителя осуществляется по заранее составленному технологом циклически повторяющемуся временному графику, в котором прописано:
__>>- момент включения тена, величина мощности, длительность
__>>- момент подачи охладителя, величина мощности охладителя, длительность.

__>>Переходы с одного состояния на другое "с включено на выключено и наоборот" называются событиями и каждое в отдельности идентифицируются. Например, если предполагается в цикле три раза включать нагрев, то будет три события вклчения, и три события выключения. Каждое из них будет иметь идентификатор наподобие HeatOn_1, HeatOn_2, HeatOn_3 — события включения нагрева, HeatOff_1, HeatOff_2, HeatOff_3 — события выключения нагрева.
__>>Аналогично для охлаждения: CoolOn_1, CoolOn_2, CoolOn_3, CoolOff_1, CoolOff_2, CoolOff_3.

__>> Все основные действия контроллера связаны с "редактированием расписания" — с изменением длительностей и величин мощностей охладителя и тена в нем. Например,
__>>действие 1 = сократить до минимума длительность охлаждения, связанного с событием СоolOn_1 и неизрасходованное на охлаждение время добавить в длительность охлаждения, отвечающего событию CoolOn_2.

__>>У технолога есть доступ к функциям, позволяющим по идентификатору события получать различную информацию, например,

__>>ЕСЛИ IsActual[СоolOn_1] AND [Weight < 1кг], ТО
__>> ЕСЛИ [@действие_1 GetProcessMaxPressure[CoolOn_2] < 300], ТО действие_1

__>>По смыслу, если в данный момент идет охлаждение вызванное событием СоolOn_1, и нагрузка на поршень невелика, то можно сэкономить, выключив охлаждение раньше времени и перенеся оставшееся время следующему по расписанию включению охлаждения при условии, что это не вызовет выход процесса за пределы 300 на интервале от текущего момента до момента наступления события CoolOn_2.

__>>В общем, как-то так. Не знаю, насколько понятно...
S>Пока понятно плохо. Надо ещё примеров

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

__>>Меня интересует, как сделать язык более простым для понимания. Декларативные языки в исходном виде как раз таковы — их понимание проще из-за того, что практически нет зависимости от порядка вычисления выражений (не нужно заморачиваться понятием control flow).
S>Ну, в этом месте вы противоречите сами себе — выше по тексту вы рассказывали, что "следующие" выражения вычисляются после выполнения действий, заданных предыдущими выражениями. Тут никакой декларативности нет.

Изначально, ведя речь про декларативность, я говорил о декларативности "подъязыка" вычисления выражений — как его расширить путем введения вычисления в контексте и при этом не начать зависеть о порядка вычисления выражения. То, о чем вы говорите — это другая часть моего языка — язык выбора действий. Он, действительно, не декларативный, поскольку есть жесткая зависимость от порядка проверки условий.

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

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

__>Кхм...То есть, понять, что конструкция [@включить_тен P*V @] означат "произведение давления на объем при включенном тене" — это свернуть мозг? Хоть аудитория у меня и без высшего образования, но, думаю, не умственно отсталые.
Да, свернуть мозг. Я объясню, почему — вы хотите разрешать смешивать в формулах разные контексты.
Даже обычную-то формулу проверить одним взглядом бывает тяжело, а вы добавляете целое отдельное измерение. Я считаю это опасным усложнением.

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

__>Смысл в этом примере в том, что технологу известен факт: при максимальном объеме цилиндра охладитель всегда сбивает температуру ниже 1000 градусов, какой бы процесс не происходил. Потому и проверяется, что если при текущем объеме нельзя будет аварийно с помощью охладителя опустить температуру, то во избежание невозможности снижения температуры в будущем нужно увеличить объем до максимального. (Это сродни тому, как водитель прикидывает, что если при включении тормоза не сможет успеть затормозить до столкновения с впереди идущей машиной, то нужно увеличить это расстояние до максимального, чтобы торможение наверняка приводило бы к безаварийной остановке.)
Отлично, я так и подозревал. То есть вы хотите сказать, что есть некое неявное предположение, которое в программе никак не выражено, так? Вот тут я радикально против, т.к. это мешает писать корректные программы. Если у нас есть какие-то инварианты, они должны быть известны компилятору, а дальше пускай он следит за корректностью программы. Каждому — своё: технолог знает, какие процессы предпочтительны, и какие значения у параметров являются граничными. Другой технолог должен быть способен взглянуть на программу, написанную первым технологом, и сразу понять, верна она или нет, и где нужно исправить, если что-то не соответствует действительности.

S>>>>А по поводу 3.1. в моём варианте есть готовое решение "проверки последствий": благодаря тому, что оператор можно применять рекурсивно, можно обрамить всю программу единым пост-условием:
S>>>>ВыбратьДействиеПоТехПроцессуПутёмАнализаМногоЧегоИСложного
S>>>> ЕСЛИТОГДА T < TВзрыва AND P < PВзрыва
S>>>> ИНАЧЕ ВключитьАварийнуюЗащиту

__>>>В моем случае все было гораздо проще — просто в конце программы записывается:

__>А-аа, теперь понял, о чем вы. Да, тогда у меня одной глобальной проверки, упреждающей критические последствия выполнения выбранного действия, сделать нельзя будет. Можно будет определить это одним условием, типа L = <проверка на некритичность параметров>, а после в каждой ветке, способной запустить действие <action> вставлять в конце, перед запуском, условие:
__>

__>... ЕСЛИ [@<action> L@], ТО <action>
__>

__>Дубляж...Да. Ок. Признаю еще одно достоинство. Но, я так понимаю, оно возможно только потому, что вы до самого последнего конца не запускаете действие, а только его отбираете в качестве претендента. Тогда возможно отсюда вылазит и недостаток — а как в вашем варианте осуществить запуск нескольких действий одновременно? Если же, как вы пишете:

S>>Ну, у меня это "работает" очень просто: программа состоит из блоков; каждый блок анализируется и из него выбирается либо 0 либо 1 действие. Выбранные действия из каждого блока запускаются.

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

__>Возвращаясь еще раз к
__>>>>>

__>>>>>если [@C1 <exprs_1> ] < [@C2 <exprs_1>], то
__>>>>>    если [@C2 <exprs_1> ] > [@C2 <exprs_2>], то C2
__>>>>>иначе С1
__>>>>>

__>>>>>(Кстати, как в вашем варианте оно запишется? Что-то не могу сообразить...)

S>>>>

S>>>>ИЗ C1, (С2 ЕСЛИТОГДА <exprs_1> > <exprs_2> ИНАЧЕ С1) ВЫБРАТЬ МИНИМИЗИРУЮЩЕЕ <exprs_1> 
S>>>>

__>Вам не кажется, что последняя запись очень "технична" — ее сложно перевести на человеческий язык.
Кажется. Она технична ровно настолько же, сколь и оригинал. Его-то тоже невозможно перевести на человеческий язык. Вот если бы вы привели пример настоящей программы, устроенной таким образом, а не абстрактного синтаксического дерева, то можно было бы что-то обсуждать.

Добавьте сюда еще случай, когда у вас будет несколько вложенных ЕСЛИ, тогда у вас пойдут вложенные ВЫБРАТЬ МИНИМИЗИРУЮЩЕЕ — читабельность стремится к нулю. К тому же, как записывать сразу такие конструкции, не переводя их подобно тому, как вы делали выше с моих, мне трудно представить. Например, как просто на вашем языке можно записать это:

__>

__>если [@C1 <exprs_1> ] < [@C2 <exprs_1>], то
__>    если [@C2 <exprs_1> ] > [@C2 <exprs_2>], то 
__>        если [@C2 <exprs_1> ] < [@C3 <exprs_1>], то C2,
__>        иначе С3
__>    иначе С1
__>иначе С0
__>

__>?
Вы идетё не по тому пути. Понятно, что на каждом из диалектов можно придумать программу, неудобную для другого. Поймите, что как только язык зафиксирован, пользователь начинает думать на нём, а не на воображаемом "другом диалекте", поэтому "проблемы перевода" стоять не будет.
А если вам хочется помериться тем, что легче записать, попробуйте усложнить свой пример с выбором между температурами:

ЕСЛИ "текущая температура < 30" ТО 
  ИЗ "поднять температуру на 35 градусов", "поднять температуру на 50 градусов", "поднять температуру на 70 градусов" 
  ВЫБРАТЬ МАКСИМИЗИРУЮЩЕЕ "давление * объем^(3/2)"

Как это будет выглядеть на вашем варианте языка?

__>Ну что ж непонятного. Представьте — вы Бог и создаете животное. Вы говорите, пока хочу, чтобы оно было очень сильным и неуязвимым, а потом, если будет надо, добавим "фич". И создаете слона. А потом вам захотелось добавить фичу "умеет летать". С вашей позиции это звучит так: "подумаешь, проблемы — просто расширим его за счет добавления крыльев". На деле же оказывается, что это принципиально несовместимые "фичи", а потому надо либо заново "пересоздавать" животное, либо отказаться от "полетов".
Плохая аналогия. Впрочем, пойдёт. Какую мораль вы из неё извлекаете? Я — ту, что нужно добавлять вещи с минимальным разрушительным эффектом. Ваши context-bound вычисления — это too big gun. Они слишком далеки от реальных сценариев, чтобы быть выразительными, и слишком мощны, чтобы быть безопасными.

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

__>>>Не хотел, конечно, в это влазить, но видимо придется...
__>>>Итак, наверное можно считать так: подгорев газа, подача охладителя осуществляется по заранее составленному технологом циклически повторяющемуся временному графику, в котором прописано:
__>>>- момент включения тена, величина мощности, длительность
__>>>- момент подачи охладителя, величина мощности охладителя, длительность.

__>>>В общем, как-то так. Не знаю, насколько понятно...
S>>Пока понятно плохо. Надо ещё примеров

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

__>Изначально, ведя речь про декларативность, я говорил о декларативности "подъязыка" вычисления выражений — как его расширить путем введения вычисления в контексте и при этом не начать зависеть о порядка вычисления выражения. То, о чем вы говорите — это другая часть моего языка — язык выбора действий. Он, действительно, не декларативный, поскольку есть жесткая зависимость от порядка проверки условий.

Ок, понятно. В целом, я считаю, что вы сделали только одну ошибку — способ декомпозиции задачи. Вы разделили задачу "выбрать действия" и задачу "вычислить выражение", и при этом отвлеклись от пользовательских сценариев. Пока вы не откажетесь от этой декомпозиции, вы не сможете добиться существенного улучшения. Ваш нынешний синтаксис — не лучше и не хуже любого другого. Можно поэкспериментировать с
— порядком задания контекста (до либо после выражения)
— видом скобочек (квадратные могут потребоваться для индексации массивов)
— вопросами каскадирования контекстов (ЕСЛИ ПОСЛЕ [УвеличитьОбъём И ПодатьОхладитель] T > 1000 ТО БегиФорестБеги)
Но в целом всё останется не лучше, чем сейчас.
Постарайтесь выделить основные типы "мудрости технологов" в виде эвристик; классифицируйте эти эвристики и придумайте максимально понятный и выразительный язык для каждого из типов. Не бойтесь вводить несколько операторов — людям наплевать на "синтаксический минимализм". В конце концов, любую программу можно записать в виде нулей и единиц — это не означает, что людям ими пользоваться проще, чем целым алфавитом.

Здравствуйте, Sinclair.

Спасибо за советы. Попробую их учесть в языке.
П.С. И кстати, я вспомнил... Я отказался от конструкций наподобие ARGMAX[<expression>, <context1>,...,<contextk>] (аналог вашего ВЫБРАТЬ ИЗ<context1>,...,<contextk> МАКСИМИЗИРУЩИЙ [@<context> <expression> @] ) по той причине, что это "неведома зверушка" — берет на вход выражение в символьном виде и пытается его внутри вычислять в контексте. Сразу же появляется зависимость от порядка вычислений — сначала должен быть применен контекст, и только потом "развернуто выражение", но никак не наоборот.

E1: P*V
ARGMAX[E, C1,C2]

При аппликативном порядке:

ARGMAX[E, C1,C2] -> ARGMAX[P*V, C1,C2] -> ARGMAX[20*100, C1,C2] -> ARGMAX[2000, C1,C2] -> List[C1,C2][[ArgMax[ [@C1 2000], [@C2 2000] ]]] -> List[C1,C2][[ArgMax[2000, 2000]]] -> List[C1,C2][[1]] -> C1

При нормальном:

ARGMAX[E, C1,C2] -> List[C1,C2][[ArgMax[ [@C1 E], [@C2 E] ] ]]  -> List[C1,C2][[ArgMax[ [@C1 P*V], [@C2 P*V] ] ]] ->   List[C1,C2][[ArgMax[ 20*30, 100*40 ] ]] -> List[C1,C2][[ArgMax[ 600, 4000] ]] -> List[C1,C2][[2]] -> C2.

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

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

__>Здравствуйте, Sinclair.

__>Спасибо за советы. Попробую их учесть в языке.
__>П.С. И кстати, я вспомнил... Я отказался от конструкций наподобие ARGMAX[<expression>, <context1>,...,<contextk>] (аналог вашего ВЫБРАТЬ ИЗ<context1>,...,<contextk> МАКСИМИЗИРУЩИЙ [@<context> <expression> @] ) по той причине, что это "неведома зверушка" — берет на вход выражение в символьном виде и пытается его внутри вычислять в контексте.
Непонятно, в чём проблема. Уже ваша конструкция [@<context> <expression> @] берет на вход выражение в символьном виде и пытается его внутри вычислять в контексте.

__>Сразу же появляется зависимость от порядка вычислений — сначала должен быть применен контекст, и только потом "развернуто выражение", но никак не наоборот.
Это потому, что вы пытаетесь обойтись скудными средствами, имея абстрактную "функцию контекстов и выражений" для записи всех прикладных сценариев
В C# это было бы уместно — потому что язык ограничивает. Там бы я согласился с тем, чтобы иметь

public Action ArgMax<T>(Expression<T> expression, params Action contexts[])
  where T:IComparable<T>

__>

__>E1: P*V
__>ARGMAX[E, C1,C2]
__>

__>При аппликативном порядке:

__>[code]
__>ARGMAX[E, C1,C2] -> ARGMAX[P*V, C1,C2] -> ARGMAX[20*100, C1,C2] -> ARGMAX[2000, C1,C2] -> List[C1,C2][[ArgMax[ [@C1 2000], [@C2 2000] ]]] -> List[C1,C2][[ArgMax[2000, 2000]]] -> List[C1,C2][1]] -> C1
Это если отказаться от использования не только операторов, но и замыканий. Ну и понятно, что такой подход не имеет физического смысла. Если вы хотите обойтись только "контекстными выражениями", оставив функции обычными (т.е. в стиле C), то вообще ничего не получится — как ни прыгай, а передать список контекстов в ArgMax не удастся (они не являются значениями).
А если вы вводите концепции контекстов и замыканий как first-class objects, то само понятие "выражение в контексте" можно записать в виде библиотечной функции @(Context context, Expression expression), не являющейся частью языка.

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

__>Стоит задача создания специализированного языка для [...]

Если вдруг эта тема ещё актуальна, то предлагаю пример реального DSL. Когда-то очень давно был такой проект — "Script Reporter", это умершая библиотека на Delphi для создания бумажных отчётов, где структура и логика построения отчётов задавалась через скриптовый язык. В своё время для меня этот проект стал учебником как создавать свой DSL, и на практике подобные DSL-и успешно применялись. Язык декларативный, очень простой, напоминает SQL, немного паскале-подобный, есть ряд вещей, похожих на то, что здесь уже обсуждали. Используется понятие контекста исполнения, в т.ч. и событийность. Подобный язык осваивается легко и быстро любым специалистом-непрограммистом, достаточно базовых навыков по информатике. В качестве IDE вполне достаточно текстового редактора с настроенной подсветкой синтаксиса, "высший шик" — автодополнение из словаря данных (имена функций, ключевые слова и т.д.) плюс дополнение из уже введенных слов в тексте (в тех же vim/emacs, или SublimeText как решение попроще, есть всё, что нужно, "из коробки").

Выкладываю из древних архивов help-файл этого проекта, документ маленький, для общего представления достаточно быстро просмотреть "по диагонали", рекомендую сначала глянуть на примеры.

Скачать: sr_help.zip

	От:	_hum_
	Дата:	04.01.13 12:56
	Оценка:

	От:	deniok
	Дата:	04.01.13 13:17
	Оценка:

От:	AlexCab	LinkedIn
Дата:	04.01.13 14:21
Оценка:

От:	VladD2	www.nemerle.org
Дата:	04.01.13 15:50
Оценка:	1 (1)

	От:	_hum_
	Дата:	05.01.13 12:19
	Оценка:

	От:	Ромашка
	Дата:	09.01.13 12:37
	Оценка:	+1

От:	Sinclair	https://github.com/evilguest/
Дата:	11.01.13 05:43
Оценка:

	От:	Буравчик
	Дата:	11.01.13 23:45
	Оценка:

	От:	rfq
	Дата:	06.01.13 17:55
	Оценка:

	От:	rfq
	Дата:	10.01.13 03:47
	Оценка:

	От:	WolfHound
	Дата:	10.01.13 16:45
	Оценка:

	От:	WolfHound
	Дата:	10.01.13 16:54
	Оценка: