Existe-t-il une déclaration «quand»? [fermé]

Existe-t-il une langue ou une fonctionnalité de langue qui peut gérer les cas «quand»? Autrement dit, chaque fois qu'une condition devient vraie, dans n'importe quelle portée ou contexte, ce code supplémentaire pourrait être spécifié pour s'exécuter?

Notez que ceci est différent d'un simple if, qui doit être dans une portée particulière et explicitement écrit. Cette clause when serait presque comme une clause ifqui s'applique à chaque cas dans l'exécution du programme après.

Votre question n'est pas claire mais le modèle Observer semble être ce que vous recherchez http://en.wikipedia.org/wiki/Observer_pattern

En ce qui concerne la syntaxe, plusieurs langues ont un whenmot - clé, mais je ne connais aucune langue qui l'utilise comme vous le décrivez.

Le modèle `` quand X se produit, faites Y '' est en quelque sorte le cœur de la programmation orientée vers l'aspect: au lieu de définir un flux linéaire, vous accrochez les gestionnaires dans certaines conditions (alias 'abonnement' à un 'événement'). Ce type de programmation est populaire dans les applications GUI, où la routine de base du programme est un répartiteur d'événements.

Certains langages ont des fonctionnalités de syntaxe étendues pour fournir de tels mécanismes à travers des constructions de langage; un exemple serait C # avec ses délégués et événements:

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

D'autres langages utilisent des constructions OOP (modèle Observer, écouteurs d'événements, etc.; un exemple en Java (mon Java est un peu rouillé, alors n'hésitez pas à le modifier):

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

Pourtant, une autre approche utilise de simples anciens rappels. Exemple en javascript:

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

Personne n'a encore parlé INTERCAL de comefrom :

COMEFROM a été initialement vu dans des listes d'instructions de langage d'assemblage de blague (comme «CMFRM»). Il a été développé dans un article de Datamation de R. Lawrence Clark en 1973, écrit en réponse à la lettre de Go To Statement considérée comme nuisible par Edsger Dijkstra. COMEFROM a finalement été implémenté dans la variante C-INTERCAL du langage de programmation ésotérique INTERCAL avec le COMEFROM encore plus obscur. Il y avait également des propositions de Fortran pour «affecté COME FROM» et un mot clé «DONT» (pour compléter la boucle «DO» existante).

Le 1er avril 2004, Richie Hindle a publié une implémentation de GOTO et COMEFROM pour le langage de programmation Python. Bien qu'elle soit publiée le jour du poisson d'avril et qu'elle ne soit pas destinée à un usage sérieux, la syntaxe est valide et la mise en œuvre fonctionne pleinement.

Le langage Tcl a des traces sur les variables qui permettent d'exécuter du code arbitraire chaque fois qu'une variable est définie (ou lue ou supprimée, mais c'est moins important ici). Ce code arbitraire peut facilement inclure l'évaluation d'une expression et l'exécution de code si elle se vérifie. La principale contrainte est que, bien que vous puissiez le faire pour les variables locales, ce n'est généralement pas très utile car elles ont tendance à avoir une durée de vie très courte, de sorte que ces choses sont généralement limitées aux variables globales et d'espace de noms. (Tcl n'a pas de fermetures.)

Mais si vous faites cela, vous devez être prudent. Bien que vous n'ayez pas officiellement de problèmes de réentrance (la trace est désactivée pendant la durée de l'exécution du corps), c'est toujours un excellent moyen d'écrire du code très peu clair et de créer beaucoup de confusion. C'est aussi une très mauvaise idée de l'utiliser avec une variable de boucle (autre que pour le débogage) car les performances peuvent être assez importantes.

Un exemple (basé sur le code de la page de manuel liée ci-dessus) illustre.

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

À partir de ce moment, chaque fois que l'un $fooou l' autre $bardevient un nouvel entier, $foobardevient le produit des deux. Automatiquement.

Tcl permet également de configurer le code à exécuter sur d'autres types de déclencheurs, tels que l'exécution de commandes, la suppression de commandes, les minuteurs, les données devenant disponibles sur les sockets, etc. Avec la bibliothèque Tk ajoutée, elle est étendue pour inclure un ensemble complet des événements GUI ainsi. Il est vrai que Tcl est en fait un langage très fortement orienté événement (même si vous pouvez facilement écrire du code qui n'utilise jamais aucune de ces fonctionnalités).

Quelque chose comme la gestion des événements?

au lieu de func () gère l'événement

vous dites quand l'événement fonctionne

Ou, peut-être un rappel sur une variable particulière?

Oui, il existe un tel mot-clé en Perl, en tant que modificateur d'instruction:

say 'Well done!'        when 'A';

Cela fait également partie de l'instruction switch:

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

Est- ceCOMEFROM que cela ( déclaration décrite sur Wikipedia) compte?

Sommaire:

COMEFROM est à peu près l'opposé de GOTO en ce sens qu'il peut prendre l'état d'exécution de n'importe quel point arbitraire de code dans une instruction COMEFROM. Le point dans le code où le transfert d'état se produit est généralement donné comme paramètre à COMEFROM. Que le transfert ait lieu avant ou après l'instruction au point de transfert spécifié dépend de la langue utilisée. Selon le langage utilisé, plusieurs COMEFROM référençant le même point de départ peuvent être invalides, non déterministes, être exécutés dans une sorte de priorité définie, ou même induire une exécution parallèle ou autrement concurrente comme vu dans Threaded Intercal.

Recherchez-vous une langue avec une instruction Synchrone ou Asynchrone When?

Cela ressemble à un modèle d'événement (/ abonnement / rappel) pour moi.

Par exemple

conditionOwner.Condition += listener.WhenCondition

Chaque fois que le propriétaire de la condition notifie que la condition a eu lieu, l'écouteur fait WhenCondition ().

Vous pouvez utiliser un modèle de liaison avec un convertisseur qui vérifie l'état de plusieurs variables d'entrée (en cas de modification) et calcule la condition, puis avoir une propriété d'entrée d'écouteur liée à la sortie et agir lorsque cette entrée est modifiée.

En ce qui concerne les langages, .NET par exemple (c'est-à-dire C #) a intégré des abonnements synchrones (événements) et ses extensions réactives (RX) ajoutent des abonnements asynchrones.

La description ressemble à un déclencheur de base de données qui est conçu pour attendre un certain scénario, puis pour s'exécuter.

De Wikipédia:

Un déclencheur de base de données est un code procédural qui est automatiquement exécuté en réponse à certains événements sur une table ou une vue particulière dans une base de données. Le déclencheur est principalement utilisé pour maintenir l'intégrité des informations sur la base de données. Par exemple, lorsqu'un nouvel enregistrement (représentant un nouveau travailleur) est ajouté à la table des employés, de nouveaux enregistrements doivent également être créés dans les tables des taxes, des vacances et des salaires.

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

Ce dont vous parlez, c'est moins de syntaxe que de structure . Vous ne pouvez vraiment avoir qu'une wheninstruction comme celle-ci dans un système qui exécute une quantité finie de logique, puis exécute les wheninstructions, puis boucle et exécute à nouveau la logique, en continuant dans une boucle infinie.

Par exemple, la programmation Windows est généralement "basée sur les événements". S'abonner à l' Clickévénement d' un bouton signifie essentiellement "faire cela lorsque vous cliquez dessus". Cependant, ce qui se passe sous le capot est une boucle de traitement des messages. Windows envoie un message à l'application lorsque l'utilisateur clique sur le bouton et la boucle de traitement des messages dans l'application exécute le gestionnaire d'événements approprié.

Si vous utilisez des événements dans, par exemple, C #, vous pouvez le faire sans boucle de message, mais la limitation est que vous devez déclarer l'événement à l'avance, vous ne pouvez donc pas écrire une wheninstruction artibrary qui surveille tout type de Etat. Vous devez attendre un événement spécifique.

Pour obtenir ce comportement dans une architecture Von Neumann, vous devez exécuter une sorte de boucle infinie qui vérifie toutes les conditions à chaque fois dans la boucle exécutant le code approprié, le cas échéant. En interne, vous obtenez simplement une grande liste de if/ thenou switchdéclarations. La plupart des applications de bureau et des programmeurs Web vomiraient s'ils voyaient une telle construction, donc ce n'est vraiment acceptable que si vous l'enveloppez dans une sorte de sucre syntaxique comme le modèle d'événement Windows (même si c'est ce qui se passe sous le capot).

D'un autre côté, si vous regardez le domaine du développement de firmware embarqué, des cadres en temps réel ou des contrôleurs industriels, ce modèle de programmation est très courant. Par exemple, si vous avez un programme en temps réel, vous voudrez peut-être exprimer:

outputA = input1 && input2

Le code est simple à comprendre (car il est déclaratif). Cependant, pour le faire fonctionner, vous devez l'exécuter en boucle serrée. Vous réévaluez outputAchaque fois à travers la boucle. Beaucoup de programmeurs de bureau ou Web n'aimeraient pas cela parce que c'est inefficace. Pour eux, le seul moment où vous devez réévaluer outputAest le moment input1ou les input2changements. Ils préfèrent voir quelque chose de plus comme vous le décrivez:

when input1 changes
    evaluateOutputA()

when input2 changes
    evaluateOutputA()

evaluateOutputA()
    outputA = input1 && input2

Maintenant, si c'est ce que vous voulez (et personnellement, je ne préfère pas cette idée), et votre objectif est l'efficacité, alors vous devez vous demander ce que le processeur fait sous le capot. De toute évidence, il existe toujours une sorte de boucle en cours d'exécution qui compare les états d'entrée aux états d'entrée précédents à chaque fois et exécute le code approprié chaque fois que l'on change. C'est vraiment moins efficace et plus difficile à lire et plus difficile à entretenir.

D'un autre côté, si le travail que vous avez à faire lorsque des input1changements sont importants, votre whenarticle pourrait avoir un sens. Dans les automates, ce type d'instruction est appelé "détection de front montant". Il enregistre l'état de input1la dernière fois dans la boucle, le compare à la valeur cette fois et exécute la logique si le dernier état était faux et que cet état est vrai.

Si vous n'avez pas d'architecture Von Neumann, alors le jeu change. Par exemple, si vous programmez un FPGA en VHDL , alors lorsque vous écrivez:

outputA = input1 && input2

(... ou quelle que soit la syntaxe VHDL appropriée serait), le FPGA se fait câblé de telle sorte que input1et input2sont câblés à l'entrée d'une porte, et la sortie de la porte est câblé outputA. Ainsi, non seulement le code est facile à comprendre, il est également exécuté en parallèle avec toutes les autres logiques, et il est efficace.

Lorsque vous parlez d'un contrôleur industriel comme un API ou un PAC, programmé dans l'un des cinq langages CEI-61131-3, le cas typique est ce type de disposition:

1. Lire les entrées et stocker en mémoire
2. Exécuter le programme principal
3. Écrire les sorties de la mémoire sur les sorties réelles
4. Passez à l'étape 1

Ceci est intégré à l'architecture du système, il est donc prévu que vous écriviez simplement:

outputA = input1 && input2

... et il sera exécuté en boucle continue.

Il existe également des routines d'interruption sur ces machines. Ils ressemblent davantage à une prise en charge matérielle pour l' whenopérateur dont vous parlez. L' interruption matérielle est un moyen d'exécuter du code sur un événement externe. Par exemple, lorsqu'une carte réseau indique qu'elle a des données en attente, le processeur doit normalement lire ces données immédiatement ou vous manquerez d'espace mémoire tampon. Cependant, pour le nombre de fois que vous devez connecter une véritable interruption matérielle, je doute que l'inclusion d'un mot-clé de langue en vaille la peine. Vous seriez limité aux broches d'entrée du processeur et il semble que vous souhaitiez tester l'état du programme interne.

Donc, dans un langage traditionnel (sans boucle serrée qui s'exécute à l'infini), vous devez vous poser la question "quand le code d'évaluation s'exécute"?

Si vous écrivez:

when A do
    launchNukes()

... et en supposant qu'il As'agit d'une expression booléenne arbitraire, comment savoir quand réévaluer cette expression? Une implémentation naïve signifierait que vous deviez la réévaluer après chaque écriture de mémoire unique. Vous pourriez penser que vous pouvez le réduire, mais considérez ceci:

when systemTime > actionTime do
    launchNukes()

Notez que cela systemTimechange toujours (chaque fois que vous le lirez, vous obtiendrez un numéro différent). Cela signifie que la partie conditionnelle de toutes vos whenclauses doit être réévaluée en continu. C'est presque impossible (et réfléchissez juste une seconde à ce qui se passe si votre expression conditionnelle a des effets secondaires!)

Conclusion

Vous ne pouvez avoir une wheninstruction (comme vous le décrivez) dans une architecture basée sur une boucle infinie qui exécute le programme principal, puis exécute les wheninstructions si les conditions sont passées de false à true sur cette boucle. Bien que cette architecture soit courante dans les appareils embarqués et industriels, elle n'est pas courante dans les langages de programmation à usage général.

Le langage AspectJ a un modèle Join-Point, qui est une solution pour gérer exactement ce genre de situation.

Un Join-Point dans AspectJ est un événement dynamique dans un programme Java qui se produit lorsque le programme est en cours d'exécution. Voici des exemples de points de jonction: (1) Une méthode est appelée; (2) Une méthode est exécutée; (3) Un constructeur est appelé; (4) Un constructeur est exécuté; (5) Un champ est défini; ou (6) Un champ est accessible.

Vous pouvez ensuite créer des ensembles de ces points de jonction, appelés points de coupe. Les coupes de points peuvent ensuite être jointes, complétées et coupées de la manière habituelle de la théorie des ensembles. D'autres réductions de points peuvent être conditionnées aux valeurs / types de variables (par exemple, "uniquement lorsque x est positif", "uniquement lorsque la valeur définie est une sous-classe de ce type") et basées sur l'état du programme ("lorsque cette méthode est appelée, mais uniquement lorsque cette autre méthode est sur la pile de ce thread [ce qui signifie que cette méthode l'a appelée indirectement] ").

Une fois que tous ces raccourcis décrivent des événements dans le programme, vous pouvez alors utiliser AspectJ pour conseiller ces événements. Vous pouvez choisir de faire quelque chose avant que l'événement ne se produise ( beforeconseils), après que l'événement se produise ( afterconseils) ou à la place de l'événement qui se produit ( aroundconseils).

Arounddes conseils sont particulièrement utiles pour ajouter la mise en cache à vos programmes: lorsqu'une méthode est exécutée, recherchez dans un tableau pour voir si le même calcul a déjà été effectué et, si c'est le cas, utilisez la version mise en cache. Avec AspectJ, il est si léger et expressif que vous pouvez faire de telles expériences de mise en cache sur des centaines de points différents dans votre code afin de trouver si et où la mise en cache ajoute des valeurs.

Beaucoup de gens en dehors de la programmation orientée vers les aspects pensent que l'AOP concerne principalement la «journalisation». Vous pouvez utiliser AspectJ pour gérer la journalisation, et il le fait très bien ("enregistrez dans ce fichier journal lorsque toutes les méthodes publiques de ce package sont appelées et quels étaient leurs résultats / résultats d'erreur"). Mais il y a tellement plus à AspectJ, y compris une astuce astucieuse pour simuler la portée dynamique appelée Worm Hole Pattern [voir diapo 23 et suivantes].

En dehors d'AOP, vous parlez également de programmation basée sur les événements, qui inclut [comme d'autres l'ont noté] le modèle d'observateur. La différence entre les solutions est: (1) comment la condition est détectée; (2) lorsque la condition est exprimée; et (3) comment le code à exécuter est lié à l'événement.

Comment utiliser Notify / Wait semble être proche de cela:

Nous avons mentionné que le mécanisme d'attente / notification Java est essentiellement un moyen de communiquer entre les threads. En résumé, l'idée est la suivante:

• un ou plusieurs threads attendent un signal;
• un autre thread arrive et informe les threads en attente (c'est-à-dire "le réveille / les réveille" avec le signal).

Selon le contexte, certaines structures peuvent être proches de cela, mais vous devez vraiment clarifier votre question.

Il existe également une instruction "quand" dans XSLT :

L'élément est utilisé pour déterminer un plan d'action basé sur une série de tests. Chaque test est effectué à l'intérieur d'un élément. Si un test réussit, le corps de l'élément est exécuté. Si aucun test échoue, un élément peut être utilisé pour spécifier une action par défaut:

Le XSLT "quand" est une instruction conditionnelle, plus comme un commutateur qu'un if. Cependant, le contexte de ce que l'on entendait par «quand» dans la question initiale n'était pas vraiment bien clarifié.

J'utilise assez souvent les XSLT dans le CMS Sitecore où je travaille pour présenter du contenu afin qu'il puisse être utilisé dans un environnement GUI dans certains cas.

Ce que vous demandez s'appelle Programmation réactive .

C'est un paradigme de programmation où les variables sont conscientes de l'expression à laquelle elles ont été affectées et chaque fois qu'un composant de l'expression change, la variable réagit en réévaluant l'expression, déclenchant éventuellement d'autres réévaluations similaires dans la chaîne des dépendances. .

Habituellement, ce comportement réactif est obtenu grâce à une utilisation intelligente du modèle d'observation, où une valeur réactive s'inscrit en tant qu'auditeur à un ensemble d'événements qui déclenchent la réévaluation de la valeur.

À ma connaissance, il n'existe pas de langage de programmation qui engloberait entièrement la programmation réactive dans son cœur, mais il existe de nombreuses bibliothèques dans de nombreux langages offrant les avantages de la programmation réactive d'une manière ou d'une autre.

La plupart des cadres de liaison de données peuvent être considérés comme des implémentations de programmation réactive .

Il y a un beau papier sur " Déprécier le modèle d'observateur ", qui expliquera probablement beaucoup mieux que jamais, ce qu'est la programmation réactive et ce que proposerait une implémentation au-delà des techniques déjà existantes.

Lisp (et ses nombreux dialetcs, y compris Scheme) l'a:

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

évalue do-somethinget:

(when nil 'other-thing)

évalue nilou son équivalent.

Je connais un tel type de déclaration uniquement pour la gestion des erreurs. Par exemple, BASIC ON ERROR ...ou SQL * PLUSWHENEVER SQLERROR ...

Pour les conditions arbitraires, il faudrait soit un compilateur extrêmement intelligent, soit un type de force brute assez cher (vérifier après chaque instruction) pour saisir le moment exact où les conditions deviennent vraies.

C'est une fonctionnalité des langages de flux de données tels que les langages de description du matériel (Verilog et VHDL).

En dehors de cela, je peux penser à Ada et à son mécanisme de gestion des exceptions: un gestionnaire d'exceptions est déclenché, whenune exception est déclenchée .

Il semble que vous recherchiez des variables de condition , des choses qui permettent aux threads de dormir jusqu'à ce qu'un prédicat devienne vrai.

Boost les implémente pour C ++, Apache Portable Runtime les implémente pour C. En Common Lisp, vous utiliseriez bordeaux-threadles make-condition-variable.

Si vous considérez Drools comme une langue, alors oui.

Un exemple:

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 peut gérer les signaux de manière directe en utilisant tap:

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

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

tandis que Powershell peut le gérer en utilisant une boucle d'exécution avec un bloc 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
}

comme on peut s'y attendre en utilisant 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
}

Les références

• Gérer un signal - Rosetta Code

• Tables de décision - Rosetta Code

Cela fait longtemps que je ne les ai pas regardés, je peux donc me tromper.

Si je me souviens bien, PL / I et BASIC avaient tous deux des déclarations "ON". Dans PL / I, le concept était "ON DO". En BASIC, c'était "ON", où la déclaration était généralement un GOSUB. Dans les deux langues, chaque fois que la condition spécifiée devenait vraie, les instructions associées étaient exécutées.

Vous ne voudriez pas faire ça aujourd'hui. Le compilateur doit essentiellement faire un tas de travail, pour savoir où / quand la condition pourrait devenir vraie, afin de pouvoir générer un test à ce moment-là. Une fois que vous êtes dans le gestionnaire associé, vous ne savez pas vraiment d'où vous venez, vous devez donc comprendre ce qui s'est passé pour vous y rendre, et vous ne voulez probablement pas retourner d'où vous venez.

Vous pourriez avoir un regard sur le langage OPS5 . Ses programmes sont écrits comme un ensemble de conditions. Lorsqu'une condition est remplie, l'action correspondante est exécutée. Les actions peuvent modifier l'état, ce qui peut entraîner le respect d'autres conditions. Bien qu'il n'utilise pas le whenmot - clé, il fonctionne essentiellement en effectuant des actions "quand" une condition est remplie. D' ici :

Un programme OPS5 se compose d'une section de déclaration où les constructions de données de base sont définies suivies d'une section de production où les règles de manipulation des données.

Les programmes OPS5 s'exécutent en faisant correspondre les éléments de la mémoire de travail avec les règles de la mémoire de production et en exécutant (exécutant) la règle la plus dominante qui est mise en correspondance. Le cycle Match-Select-Execute continue jusqu'à ce que le programme s'arrête explicitement ou jusqu'à ce qu'aucune règle ne puisse être mise en correspondance avec la mémoire de travail.

J'ai dû écrire une simple aventure de texte dans cette langue quand j'étais à l'université au début des années 90. C'était intéressant, mais je ne sais pas à quel point ce serait utile pour la plupart des tâches de bureau ou mobiles. Cela pourrait cependant avoir du sens dans un environnement backend.

Haskell en a un. Mais ce n'est pas une construction spéciale, juste une autre fonction http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Monad.html#v:when

Dans la plupart des langages POO, il serait possible de générer un thread supplémentaire, avec ceci comme contexte:

    while (!value)
{
}

//Execute code

Eh bien, vous pouvez écrire un tas de threads parallèles, chacun interrogeant sa condition respective. Je suppose que ce serait une application plutôt peu performante, mais c'est possible.