Was mich dazu brachte zu denken war, warum das folgende
%Vor%konnte nicht als
umgeschrieben werden %Vor% Ich schätze, das liegt daran, dass match nicht als normale Methode implementiert werden konnte, aber ich bin mir nicht sicher. Oder vielleicht war es aus Leistungsgründen.
Nun, da nun Makros verfügbar sind, wäre match möglich, stattdessen mit einem Makro implementiert zu werden? (Nicht dass es getan werden sollte, sondern nur hypothetisch)
EDIT: Dies scheint mit z. Was ist Scala's experimenteller virtueller Pattern-Matcher? ; Danke an @ om-nom-nom für das Aufzeigen.
Da es als Schlüsselwort verwendet wird, muss es nicht mit Any verknüpft werden, sodass der Compiler den Input-Typ der (Teil-) Funktion ableiten kann. Wenn es eine Methode von Any wäre, würde eine Funktion [A, B] als Argument verwendet werden.
Die praktischen Auswirkungen sind das
%Vor%verursacht den Kompilierfehler 'type mismatch'
aber ein (type parameterless) matchMethod;
%Vor%verursacht die Laufzeitausnahme 'scala.MatchError'
selbst wenn wir die Typen explizit explizit parametrisieren, erhalten wir für die folgende Situation keinen Kompilierfehler:
%Vor%Stattdessen würden wir die Laufzeitausnahme 'java.lang.ClassCastException' erhalten, da wir unter der Haube .asInstanceOf verwenden müssten.
Der andere Bonus ist Syntax-Highlighting, Matches springen im Code mehr als noch eine andere Methode, die ich glaube, dass sie verdient, da Pattern-Matches ein so wichtiger Teil von Scala ist, dass sie besondere Aufmerksamkeit verdient.
HINZUFÜGEN: Aus ähnlichen Gründen möchten Sie versuchen, Catch ein Keyword-Konstrukt zu sein, anstatt eine Funktion, die zwei Funktionen als Parameter verwendet. Übereinstimmung stimmt dann mit catch überein, was auch mit Java übereinstimmt.
Diese Antwort ist eine Erweiterung von Martin Odersky, auf die TravisBrown zuerst hingewiesen hat
samthebest's Antwort ist wahrscheinlich der wahre Grund (ich weiß nicht, das ist mir nicht vertraut), aber es gibt eine andere Art, es zu betrachten, die sich auf die funktionale Programmierung allgemeiner bezieht.
Es ist bekannt, dass Treffer in der funktionalen Programmierung ohne spezielle Sprachfunktionen gemacht werden können ( Church Encoding )
%Vor%In dieser Interpretation, wenn Sie
schreiben %Vor% Das Wort sealed ist der Wert / Ausdruck, der die Funktion match bereitstellt.
Eine Möglichkeit, Ihre Frage zu lesen, ist: Warum tun Sie das nicht einfach? Warum nicht Matches aus anderen grundlegenden Sprachfunktionen erstellen, anstatt eine syntaktische Übereinstimmung zu liefern?
Der Grund ist, dass die syntaktische match einen syntaktischen Zucker liefert, den die Leute mögen:
Überlappende Match-Funktionen:
%Vor%Verschachtelte Übereinstimmungsfunktionen:
%Vor%Das ist sehr schwierig ohne syntaktischen Zucker zu schreiben. Du kannst es schaffen; Ich habe versucht, die Möglichkeit zu erkunden, wenn versucht, monadische Extraktoren zu implementieren ; aber es ist sicher weniger schön.
Automatische Auswahl von offenen vs geschlossenen Match-Funktionen.
Das heißt, Extraktoren in Scala sind wie offene Übereinstimmungsfunktionen, da alle fehlschlagen können, indem None ; Der Compiler sucht nicht nach einem vollständigen match , aber Sie können beliebig viele verketten und Scala wählt den ersten aus. Auf der anderen Seite bieten sealed traits geschlossene Match-Funktionen mit dem Vorteil der Vollständigkeitsprüfung. Diese müssten von separaten Funktionen bereitgestellt werden, aber Scala lässt Sie für beide die gleiche match -Syntax verwenden.
Persönlich habe ich den Verdacht, dass die obigen Anforderungen letztlich keine spezielle syntaktische Unterstützung für Matches erfordern. Ich vermute, dass andere, allgemeinere Sprachmerkmale, insbesondere im Bereich der verschachtelten Matches, den gleichen Vorteil bringen können. Vorläufig ist es jedoch sinnvoller, das Problem direkt mit einer speziellen match -Syntax zu lösen.
Tags und Links scala pattern-matching scala-macros