Здравствуйте, 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