Есть ли такая вещь, как «когда»? [закрыто]

Есть ли язык или языковая функция, которая может обрабатывать случаи «когда»? То есть, когда какое-либо условие становится истинным в любой области или контексте, этот дополнительный код может быть указан для выполнения?

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

Ваш вопрос неясен, но шаблон Observer, кажется, именно то, что вы ищете http://en.wikipedia.org/wiki/Observer_pattern

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

Шаблон «когда происходит X, делай Y» является своего рода ядром аспектно-ориентированного программирования: вместо определения линейного потока вы привязываете обработчики к определенным условиям (то есть «подписке» на «событие»). Этот вид программирования популярен в приложениях с графическим интерфейсом, где основной программой является диспетчер событий.

Некоторые языки имеют обширные синтаксические возможности для обеспечения таких механизмов посредством языковых конструкций; пример будет C # с его делегатами и событиями:

// 'when btnOK is clicked, run HandleOKClick'
btnOK.Clicked += this.HandleOKClick;

В других языках используются конструкции ООП (шаблон Observer, прослушиватели событий и т. Д .; пример на Java (моя Java немного ржавая, поэтому не стесняйтесь редактировать):

Foobar f = this;
btnOK.registerClickHandler(
    new ClickHandler {
        public void handleClick(Event e) {
            f.handleOKClick(e);
        }
    });

Еще один подход заключается в использовании простых старых обратных вызовов. Пример в JavaScript:

var btnOK = $('btnOK');
btnOK.click(handleOKClick);

Никто еще не упомянул INTERCAL «s COMEFROM :

COMEFROM изначально был замечен в списках инструкций языка ассемблера (как «CMFRM»). Он был разработан в статье Datamation Р. Лоуренса Кларка в 1973 году, написанной в ответ на письмо Эдсгера Дейкстры «Перейти к заявлению, которое считается вредным». В конечном итоге COMEFROM был реализован в C-INTERCAL варианте эзотерического языка программирования INTERCAL вместе с еще более неясным «вычисляемым COMEFROM». Были также предложения Фортрана для «назначенного COME FROM» и ключевого слова «DONT» (чтобы дополнить существующий цикл «DO»).

1 апреля 2004 года Ричи Хиндл опубликовал реализацию GOTO и COMEFROM для языка программирования Python. Несмотря на то, что он выпущен в первый день апреля и не предназначен для серьезного использования, синтаксис действителен, и реализация полностью работает.

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

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

Пример (на основе кода из связанной страницы руководства выше) иллюстрирует.

set foo 1
set bar 2
proc doMult args {
    global foo bar foobar
    set foobar [expr {$foo * $bar}]
}
trace add variable foo write doMult
trace add variable bar write doMult
doMult

С этого момента, каждый раз, когда $fooили $barстановится новым целым числом, $foobarстановится продуктом двух. Автоматически.

Tcl также позволяет настроить код для запуска на другие виды триггеров, такие как выполнение команд, удаление команд, таймеры, данные становятся доступными на сокетах и ​​т. Д. С добавленной библиотекой Tk это расширяется, чтобы включать целый большой набор событий GUI, а также. Верно сказать, что Tcl на самом деле очень сильно ориентирован на события (даже если вы можете легко написать код, который также никогда не использует ни одну из этих функций).

Что-то вроде обработки событий?

вместо func () обрабатывает событие

Вы говорите, когда событие делать func

Или, может быть, обратный вызов на конкретную переменную?

Да, в Perl есть такое ключевое слово, как модификатор оператора:

say 'Well done!'        when 'A';

Это также часть оператора switch:

given ($foo) {
    when (/^abc/) { $abc = 1; }
    when (/^def/) { $def = 1; }
    when (/^xyz/) { $xyz = 1; }
    default { $nothing = 1; }
}

Имеет ли это ( COMEFROMзаявление описано в Википедии) рассчитывать?

Резюме:

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

Вы ищете язык с синхронным или асинхронным оператором когда?

Походит на образец события (/ подписка / обратный вызов) для меня.

Например

conditionOwner.Condition += listener.WhenCondition

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

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

Например, в .NET (например, C #) встроены синхронные подписки (события), а в Reactive Extensions (RX) добавлены асинхронные подписки.

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

Из Википедии:

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

http://en.wikipedia.org/wiki/Database_trigger

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

Например, программирование Windows обычно основано на событиях. Подписка на Clickсобытие кнопки по сути означает «делать это при нажатии». Однако то, что происходит под капотом, - это цикл обработки сообщений. Windows отправляет сообщение приложению, когда пользователь нажимает кнопку, и цикл обработки сообщений в приложении запускает соответствующий обработчик событий.

Если вы используете события, например, в C #, вы можете сделать это без цикла сообщений, но ограничение заключается в том, что вы должны объявлять событие заранее, поэтому вы не можете написать произвольную whenинструкцию, которая отслеживает любой вид государство. Вы должны ждать определенного события.

Чтобы получить такое поведение в архитектуре фон Неймана, вы должны запустить какой-то бесконечный цикл, который каждый раз проверяет все условия через цикл, выполняющий соответствующий код, если это необходимо. Внутренне вы просто получаете большой список if/ thenили switchутверждений. Большинство настольных приложений и веб-программистов рвало бы, если бы они увидели такую ​​конструкцию, поэтому на самом деле это только приемлемо, если вы оберните ее каким-то синтаксическим сахаром, таким как модель событий Windows (хотя это и происходит под капотом).

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

outputA = input1 && input2

Код прост для понимания (потому что он декларативный). Однако, чтобы заставить его работать, вы должны выполнить его в узком цикле. Вы переоцениваете outputAкаждый раз через цикл. Многим настольным или веб-программистам это не понравится, потому что это неэффективно. Для них единственный раз, когда вы должны переоценить outputAэто когда input1или input2изменения. Они скорее увидят что-то более похожее на то, что вы описываете:

when input1 changes
    evaluateOutputA()

when input2 changes
    evaluateOutputA()

evaluateOutputA()
    outputA = input1 && input2

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

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

Если у вас нет архитектуры фон Неймана, то игра меняется. Например, если вы программируете FPGA на VHDL , то когда вы пишете:

outputA = input1 && input2

(... или любой другой соответствующий синтаксис VHDL будет) , то FPGA , на самом деле получает проводной вверх таким образом, что input1и input2подключены к входу логического элемента, а выход логической схемы И подключен к outputA. Таким образом, код не только прост для понимания, он также выполняется параллельно со всей другой логикой и эффективен.

Когда вы говорите о промышленном контроллере, таком как PLC или PAC, запрограммированном на одном из пяти языков IEC-61131-3, типичным случаем является такая схема:

1. Читать входные данные и хранить в памяти
2. Выполнить основную программу
3. Запись выходов из памяти на фактические выходы
4. Перейти к шагу 1

Это встроено в архитектуру системы, поэтому ожидается, что вы просто напишите:

outputA = input1 && input2

... и он будет выполняться в непрерывном цикле.

В этих машинах также есть процедуры прерывания. Это больше похоже на поддержку аппаратного уровня whenоператора, о котором вы говорите. Аппаратное прерывание является средством выполнения некоторого кода на внешнее событие. Например, когда сетевая карта сообщает, что она ожидает данных, процессор обычно должен немедленно прочитать эти данные, иначе вам не хватит места в буфере. Однако из-за того, что вам нужно перехватить реальное аппаратное прерывание, я сомневаюсь, что стоит включить ключевое слово языка, так как оно того стоит. Вы будете ограничены входными контактами ЦП, и похоже, что вы хотите проверить внутреннее состояние программы.

Итак, на традиционном языке (без жесткого цикла, который работает бесконечно) вы должны задать вопрос: «когда выполняется код оценки»?

Если вы напишите:

when A do
    launchNukes()

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

when systemTime > actionTime do
    launchNukes()

Обратите внимание, что systemTimeэто всегда меняется (каждый раз, когда вы читаете это, вы получите другое число). Это означает, что условная часть всех ваших whenпредложений должна пересматриваться непрерывно. Это почти невозможно (и просто подумайте на секунду, что произойдет, если у вашего условного выражения есть побочные эффекты!)

Вывод

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

Язык AspectJ имеет модель Join-Point, которая является одним из решений для решения именно такой ситуации.

Точка соединения в AspectJ - это динамическое событие в Java-программе, которое происходит во время выполнения программы. Примеры точек соединения: (1) вызывается метод; (2) метод выполняется; (3) конструктор называется; (4) конструктор выполняется; (5) поле установлено; или (6) Доступ к полю.

Затем вы можете создать наборы этих точек соединения, которые называются pointcuts. Затем Pointcuts можно соединять, дополнять и пересекать обычным способом теории множеств. Другие сокращения точек могут быть обусловлены значениями / типами переменных (например, «только когда x положительный», «только когда устанавливаемое значение является подклассом этого типа») и основаны на состоянии программы («когда этот метод вызывается, но только когда этот другой метод находится в стеке этого потока [имеется в виду, что этот метод вызвал его косвенно] ").

После того как вы все эти события описывают срезы в в программе, вы можете использовать AspectJ , чтобы советовать эти события. Вы можете сделать что-то до того, как событие произойдет ( beforeсовет), после того, как событие произойдет ( afterсовет), или вместо события ( aroundсовет).

AroundРекомендация особенно полезна для добавления кэширования в ваши программы: когда какой-либо метод выполняется, посмотрите в таблице, чтобы увидеть, были ли выполнены те же вычисления, и, если это так, используйте кэшированную версию. С AspectJ это так просто и выразительно, что вы можете проводить такие эксперименты по кешированию на сотнях разных точек в вашем коде, чтобы определить, добавляет ли кеширование значения и где.

Многие люди, не относящиеся к аспектно-ориентированному программированию, полагают, что AOP в основном заключается в «регистрации». Вы можете использовать AspectJ для обработки журналов, и он делает это довольно хорошо («запись в этот файл журнала, когда вызываются все открытые методы в этом пакете, и каковы были их результаты / ошибки»). Но в AspectJ есть еще много чего, включая хитрый трюк для симуляции динамического объема, называемый Worm Hole Pattern [см. Слайд 23 и далее].

Помимо АОП, вы также говорите о программировании на основе событий, которое включает [как уже отмечали другие] шаблон наблюдателя. Разница между решениями заключается в том, что: (1) способ определения состояния; (2) где условие выражено; и (3) как код для выполнения связан с событием.

Как использовать Notify / Wait может показаться близким к этому:

Мы упоминали, что механизм ожидания / уведомления Java по сути является способом связи между потоками. В двух словах, идея заключается в следующем:

• один или несколько потоков ожидают сигнала;
• другой поток приходит и уведомляет ожидающие потоки (т. е. «будит его / их» с сигналом).

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

В XSLT также есть выражение «когда» :

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

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

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

То, что вы просите, называется Реактивное Программирование .

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

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

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

Большинство структур привязки данных можно считать реализациями реактивного программирования .

Есть хорошая статья под названием « Устаревание модели наблюдателя », которая, вероятно, объяснит намного лучше, чем я когда-либо мог, что такое реактивное программирование и что его реализация предложит сверх уже существующих методов.

Лисп (и многие его диалекты, включая Scheme) имеет:

(when (> 2 1) 'do-something)

оценивает do-somethingи:

(when nil 'other-thing)

оценивает nilили его эквивалент.

Я знаю такие заявления только для обработки ошибок. Например, бейсик ON ERROR ...или SQL * PLUSWHENEVER SQLERROR ...

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

Это особенность языков потоков данных, таких как языки описания оборудования (Verilog и VHDL).

Помимо этого, я могу думать об Ada и его механизме обработки исключений: обработчик исключений срабатывает, whenвозникает исключение.

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

Повышения реализует их на C ++, то Apache Portable Runtime реализует их для C. В Common Lisp вы будете использовать bordeaux-thread«S make-condition-variable.

Если вы считаете Drools языком, то да.

Пример:

rule "Rule 08 - Debit"
when
    AccountingPeriod( $start : start, $end : end )
    $cashflow : AllocatedCashflow( $account : account, $date : date <= $end, $amount : amount, type==TypedCashflow.DEBIT )
    not AccountingPeriod( start < $start)
then 
    $account.setBalance($account.getBalance()-$amount);
    retract($cashflow);
end

Perl 6 может обрабатывать сигналы напрямую, используя tap:

signal(SIGINT).tap: {
    note "Took { now - INIT now } seconds.";
    exit;
}

for 0, 1, *+* ... * {
    sleep 0.5;
    .say;
}

тогда как Powershell может справиться с этим, используя цикл выполнения с блоком try / finally:

$Start_Time = (Get-date).second
Write-Host "Type CTRL-C to Terminate..."
$n = 1
Try
{
    While($true)
    {
        Write-Host $n
        $n ++
        Start-Sleep -m 500
    }
}
Finally
{
    $End_Time = (Get-date).second
    $Time_Diff = $End_Time - $Start_Time
    Write-Host "Total time in seconds"$Time_Diff
}

как можно ожидать с помощью trap:

package require Expect

proc sigint_handler {} {
    puts "elapsed time: [expr {[clock seconds] - $::start_time}] seconds"
    set ::looping false
}

trap sigint_handler SIGINT

set start_time [clock seconds]
set n 0
set looping true
while {$looping} {
    puts [incr n]
    after 500
}

Ссылки

• Обрабатывать сигнал - Rosetta Code

• Таблицы решений - Розетта код

С тех пор, как я посмотрел на них, прошло долгое время, поэтому я вполне мог ошибиться.

Насколько я помню, PL / I и BASIC имели заявления «ON». В PL / I концепция была «ON DO». В BASIC это было «ON», где оператором обычно был GOSUB. На обоих языках всякий раз, когда указанное условие становилось истинным, выполнялись соответствующие операторы.

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

Вы могли бы взглянуть на язык OPS5 . Его программы написаны как набор условий. Когда условие выполнено, выполняется соответствующее действие. Действия могут изменить состояние, что может привести к выполнению других условий. Хотя он не использует whenключевое слово, он работает по существу, выполняя действия «когда» условие выполнено. От сюда :

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

Программы OPS5 выполняются путем сопоставления элементов рабочей памяти с правилами в производственной памяти и запуска (выполнения) наиболее доминирующего правила, которое соответствует. Цикл Match-Select-Execute продолжается до тех пор, пока программа явно не остановится или пока никакие правила не могут быть сопоставлены с рабочей памятью.

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

У Haskell есть один. Но это не специальная конструкция, это просто другая функция http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Monad.html#v:when

В большинстве языков ООП можно создать дополнительный поток, используя его в качестве контекста:

    while (!value)
{
}

//Execute code

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