Чи існує таке поняття, як "коли"? [зачинено]

Чи є мова чи мовна функція, яка може обробляти випадки "коли"? Тобто, коли якась умова стає істинною, у будь-якому обсязі чи контексті, цей додатковий код можна вказати для виконання?

Зауважте, що це відрізняється від простого if, який повинен бути у певному обсязі та чітко написаний. Це, коли пункт майже не схожий на ifте, що застосовується до кожного випадку при виконанні програми після нього.

Ваше запитання не ясно, але модель спостерігача, здається, є тією справою, яку ви шукаєте http://en.wikipedia.org/wiki/Observer_pattern

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

Шаблон 'коли X виникає, чи Y' є своєрідним ядром програмно-орієнтованого програмування: замість того, щоб визначати лінійний потік, ви підключаєте обробників до певних умов (він же "підписується" на "подію"). Цей вид програмування популярний у додатках GUI, де основним розпорядком програми є диспетчер подій.

Деякі мови мають широкі функції синтаксису, щоб забезпечити такі механізми через мовні конструкції; прикладом може бути C # з його делегатами та подіями:

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

Інші мови використовують конструкції OOP (модель спостерігача, слухачі подій тощо; приклад на Java (моя Java трохи іржава, тому сміливо редагуйте):

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

Ще один підхід - це використання звичайних старих зворотних дзвінків. Приклад у javascript:

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

Ще ніхто не згадав про КОМЕРЦІ ІНТЕРКАЛУ :

COMEFROM спочатку розглядався у списках інструкцій з мовлення анекдотів (як "CMFRM"). Це було детально розроблено у статті «Інформація» Р. Лоуренса Кларка у 1973 р., Написаній у відповідь на лист Едсгера Дайкстри «Перейти до заяви», який вважається шкідливим. Зрештою, COMEFROM був реалізований у варіанті C-INTERCAL езотеричної мови програмування INTERCAL разом із ще більш неясним "обчисленим COMEFROM". Були також пропозиції Fortran щодо "призначеного 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 () обробляє подію

Ви кажете, коли подія робить функцію

Або, можливо, зворотний виклик певної змінної?

Так, у 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, що посилаються на одну і ту ж точку відправлення, можуть бути недійсними, бути недетермінованими, виконуватись з певним певним пріоритетом або навіть викликати паралельне або інше паралельне виконання, як це видно в Threaded Intercal.

Ви шукаєте мову з синхронним або асинхронним при операторі?

Мені звучить зразок події (/ передплати / зворотного дзвінка).

Напр

conditionOwner.Condition += listener.WhenCondition

Щоразу, коли власник умови повідомляє про те, що умова відбулася, слухач виконує функцію WhenCondition ().

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

Щодо мов, .NET, наприклад (наприклад, C #), має вбудовані синхронні підписки (події), а його Реактивне розширення (RX) додає асинхронні підписки.

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

З Вікіпедії:

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

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

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

Наприклад, програмування Windows, як правило, "засноване на подіях". Підписка на Clickподію кнопки по суті означає "зробити це при натисканні". Однак, що відбувається під кришкою, це цикл обробки повідомлень. Windows надсилає повідомлення додатку, коли користувач натискає кнопку, і цикл обробки повідомлень у програмі запускає відповідний обробник подій.

Якщо ви використовуєте події, наприклад, на C #, ви можете це зробити без циклу повідомлень, але обмеженням є те, що ви повинні оголосити подію достроково, тому ви не можете написати архівну whenзаяву, яка спостерігає за будь-яким типом держава. Вам доведеться чекати конкретної події.

Для отримання такої поведінки в архітектурі Von Neumann вам потрібно запустити якийсь нескінченний цикл, який щоразу перевіряє всі умови через цикл, у якому, якщо це доречно, працює відповідний код. Всередині ви просто отримаєте великий список 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останнього разу через цикл, порівнює його зі значенням цього разу та виконує логіку, якщо останній стан був помилковим і цей стан є істинним.

Якщо у вас немає архітектури Von Neumann, то гра змінюється. Наприклад, якщо ви програмуєте FPGA в VHDL , тоді, коли ви пишете:

outputA = input1 && input2

(... або будь-який інший відповідний синтаксис VHDL буде) , то FPGA , на самому ділі отримує провідний вгору таким чином, що input1і input2підключені до входу логічного елемента, а вихід логічної схеми І підключений до outputA. Отже, код не тільки зрозумілий, він також виконується паралельно з усіма іншими логіками, і він ефективний.

Якщо ви говорите про такий промисловий контролер, як PLC або PAC, запрограмований на одній з п'яти мов IEC-61131-3, типовим випадком є ​​такий тип розташування:

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

Це вбудовано в архітектуру системи, тому очікується, що ви просто напишите:

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) Доступ до поля.

Потім можна створити набори цих точок приєднання, званих точковими розрізами. Потім точкові вирізи можна з'єднувати, доповнювати та перетинати звичайним способом теорії множин. Інші розрізи точок можуть бути обумовлені значеннями / типами змінних (наприклад, "тільки тоді, коли х є позитивним", "лише тоді, коли значення, яке встановлюється, є підкласом цього типу") та виходячи з стану програми ("коли цей метод називається, але лише тоді, коли цей інший метод знаходиться у стеці цього потоку [означає, що цей метод побічно його називав] ").

Після того, як у всіх цих точках описуються події в програмі, ви можете скористатися AspectJ, щоб порадити ці події. Ви можете зробити щось робити до того, як відбудеться подія ( beforeпорада), після того, як відбудеться подія ( afterпорада), або замість того, щоб відбулася подія ( aroundпорада).

Aroundпорада особливо корисна для додавання кешування у ваші програми: Коли виконується якийсь метод, знайдіть таблицю, щоб побачити, чи були виконані ті самі обчислення, і якщо так, скористайтеся кешованою версією. Що стосується AspectJ, він настільки легкий і виразний, що ви можете робити такі експерименти з кешування на сотнях різних точок у вашому коді, щоб знайти, чи і де кешування додає значення.

Багато людей за межами орієнтованого на аспект програмування вважають, що AOP здебільшого стосується "ведення журналу". Ви можете використовувати AspectJ для обробки журналів, і це робить це досить добре ("записуйте в цей файл журналу, коли всі загальнодоступні методи в цьому пакеті викликаються, і які були їх результати / результати помилок"). Але в AspectJ є набагато більше, в тому числі розумний трюк для імітації динамічної області дії, що називається "Шорстковий отвір" (див. Слайд 23 і далі).

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

Як користуватися Повідомлення / Зачекання , здається, це близько до цього:

Ми згадували, що механізм очікування / оповіщення Java - це, по суті, спосіб спілкування між потоками. Якщо коротко, то ідея така:

• одна або більше ниток сидить в очікуванні сигналу;
• інший потік приходить уздовж і повідомляє потоки, що очікують (тобто "прокидає його / їх" сигналом).

Залежно від контексту є деякі структури, які можуть бути близькими до цього, але вам справді потрібно уточнити своє питання.

Існує також оператор "коли" в XSLT :

Елемент використовується для визначення одного курсу дій на основі серії тестів. Кожен тест робиться всередині елемента. Якщо тест проходить успішно, тіло елемента виконується. Якщо жодних тестів не вдається, елемент можна використовувати для визначення дії за замовчуванням:

XSLT "коли" - це умовний вислів, більше схожий на перемикач, ніж на if. Однак контекст того, що малося на увазі під "коли" в первинному питанні, насправді не було чітко прояснено.

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

Те, що ви просите, називається Реактивне програмування .

Це парадигма програмування, коли змінні знають про призначений їм вираз, і кожного разу, коли компонент виразу змінюється, змінна реагує шляхом повторної оцінки виразу, можливо, викликаючи інші подібні переоцінки вниз по ланцюгу залежностей .

Зазвичай така реактивна поведінка досягається розумним використанням шаблону спостерігача, коли реактивне значення реєструється як слухач набору подій, що викликають переоцінку значення.

Наскільки мені відомо, не існує мови програмування, яка б цілком охоплювала реактивне програмування в своїй основі, але є багато бібліотек на багатьох мовах, які так чи інакше пропонують переваги реактивного програмування.

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

Існує приємний документ під назвою " Депресія моделі спостерігачів ", який, ймовірно, пояснить набагато краще, ніж я коли-небудь міг, про те, що таке реактивне програмування і що може запропонувати його реалізація понад і вже існуючими методами.

У Lisp (і його багатьох діалектів, включаючи схему) є:

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

оцінює do-somethingта:

(when nil 'other-thing)

оцінює до nilабо його еквіваленту.

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

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

Це особливість мов потоку даних, таких як апаратні мови опису (Verilog та VHDL).

Крім цього, я можу подумати про Ада та її механізм обробки винятків: спрацьовує обробник 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 може обробити це за допомогою циклу запуску з блоком спробувати / остаточно:

$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
}

Список літератури

• Обробка сигналу - Код Розетти

• Таблиці рішень - Код Розетти

Минув довгий час, як я подивився на них, тож я міг помилитися.

Як я пам'ятаю, PL / I та BASIC обидва мали заяви "ON". У PL / I поняття було "НА ДОБРО". У 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

У більшості мов OOP можна створити додатковий потік, маючи це як контекст:

    while (!value)
{
}

//Execute code

Ну, ви можете написати купу паралельних ниток, кожна з яких опитується відповідно до своєї умови. Я припускаю, що це було б досить ефективним додатком, але це можливо.