Ich frage mich, ob if … else mit einer speziellen Compilerbehandlung in Predef implementiert werden könnte, ähnlich wie bei classOf[A] : Die Definition ist in Predef , die Implementierung ist ausgefüllt vom Compiler.
Zugegeben, viele Leute würden es beruhigend finden zu wissen, dass ein if immer ein if ist, und ein else ist immer ein else , unabhängig vom Kontext. Wenn Sie jedoch else als Methode für den Ergebnistyp if definieren, wird sie aus der Liste der Schlüsselwörter entfernt, und Bibliotheksdesigner können ihre eigenen else -Methoden definieren. (Ich weiß, dass ich ein beliebiges Schlüsselwort als Bezeichner mit Backticks verwenden kann, aber etwas wie 'else' sieht im Code nur schrecklich aus.) Solche Methoden könnten in Situationen wie dieser, der auf der Mailing-Liste diskutiert wird , wo Leute otherwise verwenden müssen, wenn sie Methoden definieren, die eigentlich als% co_de bezeichnet werden sollten %. (Auch diskutiert auf SO hier und hier .)
Also:
Vielleicht verstehe ich Ihre Frage nicht, aber Sie können if ... else ... bereits als Bibliotheksfunktion implementieren. Bedenken Sie Folgendes:
Natürlich macht das nicht genau was if ... else ... macht, aber mit etwas Polieren denke ich es. Ich habe einmal einen sehr einfachen Interpreter für eine Sprache implementiert, bei der die Mustererkennung mit if ... else ... implementiert wurde, ähnlich wie hier.
Die kurze Antwort ist "ja"; Die Verzweigungslogik eines Prädikats kann als Bibliotheksfunktion implementiert werden.
Es ist erwähnenswert, dass, wie Viktor Klang und andere bemerkt haben, if / else im Wesentlichen einen booleschen Wert faltet. Falten ist etwas, was wir häufig machen - manchmal ist es klar und deutlich und manchmal nicht.
%Vor%Das Falten einer Option kann nicht explizit ausgeführt werden, aber wir tun es immer.
%Vor%Die Verzweigungslogik auf einem booleschen Wert ist ebenfalls eine Falte, und Sie können den Booleschen Wert entsprechend anpassen. Beachten Sie die Verwendung von Parametern für den Namen, um eine faule Auswertung zu erreichen. Ohne dieses Feature wäre eine solche Implementierung nicht möglich.
%Vor%Jetzt können wir Booleans falten:
%Vor% Nicht nur if-else , sondern beliebige Sprachfunktionen können in einem Zweig der Sprache "Scala Virtualized"
Dies bildet die Grundlage des Delite-Projekts bei Stanford PPL und steht auch im Mittelpunkt der Forschung, die durch das EU-Stipendium von Scala finanziert wird. Sie können also davon ausgehen, dass es irgendwann in der Zukunft zu einem Teil der Kernsprache wird.
Jede objektorientierte Sprache (oder beliebige Sprache mit Laufzeitpolymorphismus) kann Bedingungen als Bibliotheksfunktion implementieren, da der Methodenversand ohnehin ohnehin eine allgemeinere Form der Bedingung ist . Zum Beispiel hat Smalltalk absolut keine Bedingungen außer dem Methodenversand.
Es gibt keine Notwendigkeit für irgendeine Art von Compiler-Magie, außer vielleicht für syntaktische Bequemlichkeit.
In Scala würde es vielleicht ein bisschen so aussehen:
%Vor%Fügen Sie einfach eine kleine implizite Konvertierung hinzu:
%Vor%Und jetzt können wir es benutzen:
%Vor%[Anmerkung: mein Typ-Fu ist ziemlich schwach. Ich musste ein wenig schummeln, um dies innerhalb eines vernünftigen Zeitrahmens zu kompilieren. Jemand mit einem besseren Verständnis von Scalas Typsystem könnte es reparieren wollen. Außerdem, jetzt, wo ich es mir ansehe, scheinen 8 Klassen, Eigenschaften und Objekte, von denen zwei abstrakt sind, ein wenig überentwickelt zu sein ;-)]
Das Gleiche gilt natürlich auch für die Mustererkennung. Jede Sprache mit Mustererkennung benötigt keine anderen Arten von Bedingungen, da die Mustererkennung sowieso allgemeiner ist.
[BTW: Das ist im Grunde ein Port von diesem Ruby-Code , den ich vor ein paar Jahren zum Spaß geschrieben habe.]
Tags und Links scala if-statement keyword control-flow