Julia: Vorschlag: Funktionsverrohrung verwerfen und dann entfernen

Funktions-Piping stellt eine Postfix-Syntax für den Funktionsaufruf bereit, was bei der REPL zur interaktiven Datengenerierung und weiteren Visualisierung/Zusammenfassung praktisch ist.

Ein Anwendungsfall, den ich bei vielen Leuten gesehen habe, ist

julia> somecomplicatedthingproducingarray
...

<ARROW UP>

julia> somecomplicatedthingproducingarray |> summarize

wobei die Funktion summarize so etwas wie ein Diagramm oder ein Histogramm ist

@jiahao Ich behaupte nicht, dass es nicht nützlich ist, sondern dass wir innerhalb von Base konsistent sein und Pakete solche Dinge bereitstellen sollten.

es gibt auch ans für die Repl-Nutzung

Würde in diesem Vorschlag |> immer noch als Infix-Operator geparst?

@ajkeller34 : definitiv, Pakete könnten damit tun, was sie wollen (obwohl sie in Bezug auf Typpiraterie und Koexistenz gut miteinander spielen müssten), ohne eine so große Einschränkung, semantisch mit dem Alten kompatibel zu sein Basisdefinition.

Verwendungen der Syntax in Base entfernen, falls vorhanden

Hier ist ein inzwischen sehr veralteter Versuch, den ich unternommen habe: https://github.com/tkelman/julia/commit/212727cdc4aaa3221763580f15d42cfe198bcc1c
Zu dieser Zeit waren die meisten Anwendungen in Base ziemlich trivial. Einige der Verwendungen von „dieses Ding zu dieser anonymen Funktion leiten“ in den Tests sind vielleicht besser mit der Leitung verbunden, aber da die meisten von ihnen dieselbe anonyme Funktion mehrmals wiederverwendeten, würde es sich wahrscheinlich lohnen, ihr einen Namen zu geben und sie wie a zu nennen normale Funktion zu diesem Zeitpunkt.

Falls jemand neugierig ist, ich habe jetzt ChainRecursive.jl herausgebracht. Ich werde eine Ankündigung über den Zerfall von ChainMap.jl und seinen verschiedenen untergeordneten Elementen veröffentlichen, sobald es abgeschlossen ist.

Lassen Sie mich hier etwas Widerstand leisten, da ich ein gewisses Interesse und eine besondere Vorliebe für das habe, was |> ermöglicht.

Ich unterstütze @jiahao , dass |> sehr nützlich ist, wenn Sie schnell Dinge in der REPL ausprobieren möchten. Außerdem finde ich es auch nützlich, wenn Ihr Argument zu groß ist oder eine gewisse Gelassenheit verdient (ja, das habe ich gesagt) . Im Fall des verlinkten Beispiels ist es tatsächlich besser, wenn das Argument prominenter ist als die aufgerufene Funktion. sum(x) ist ein zu einfaches Beispiel und sollte eigentlich als sum(x) geschrieben werden). In Escher.jl haben alle Funktionen, die Eigenschaften zu Elementen hinzufügen, eine Curry-Methode. Das passt so gut zu |> (das war geplant, es funktioniert auch super mit map ) und es ist eine Freude, am Ende der Reihe Dinge ausprobieren zu können und das UI-Update zu sehen sofort. Ich muss nicht zum Anfang des Ausdrucks suchen und herumfummeln. Zumindest für die Verwendung mit Escher besteht die vorgeschlagene Alternative darin, Variablen mit erfundenen Namen wie padded_box_contents_aligned_right_tomato_background (oder schlimmer box34 ) große Ausdrücke zuzuweisen und dann eine Funktion für sie aufzurufen. Im Gegensatz zu den schön lesenden <big UI expression> |> aligncontents(right) |> pad(1em) |> fillcolor("tomato")

Ich weiß, dass ich danach |> in Escher definieren kann, und das werde ich wahrscheinlich auch tun, aber es wird mein Gehirn töten, wenn ich sehe, dass WARNING: using Escher.|> in module YourPackage conflicts with an existing identifier. -Pakete dem fast definitiv unterschiedliche Bedeutungen geben, was für mich sehr ist alarmierend!

StefanKarpinski und andyferris haben uns in #17155 eine beliebige Funktionskomposition gegeben, die in vielen Situationen einem ähnlichen Zweck dienen kann.

Die Alternative zu box |> fill("orange") |> pad(2em) wäre (fill("orange") ∘ pad(2em))(box) im Gegensatz zu box |> fill("orange") ∘ pad(2em) ? Diese beiden scheinen orthogonal zu sein.

Eschers Verwendung von Closures als Objekte scheint mir, als würde es eine DSL definieren, nur um diese Syntax zu verwenden (die ernsthafte Einschränkungen für alles hat, was nicht Single-Input, Single-Output ist), wo es wahrscheinlich besser bedient wäre , und verallgemeinerbarer, wenn es eines der mehreren verfügbaren Verkettungsmakros verwendet.

Das Entfernen der Definition von Base würde es Leuten, die diese Syntax mögen, ermöglichen, interessantere Dinge damit zu tun.

@shashi Ich verstehe Ihre Punkte, aber Sie könnten dasselbe Verhalten mit einem der Pakete erzielen, die ich in der Ausgabe zitiert habe, oder? Beispielsweise könnten Sie in Ihrem Escher-Beispiel FunctionalData verwenden, um <strong i="6">@p</strong> vbox(<really big thing>) | pad(2em) auszuführen, oder Lazy, um @> vbox(...) pad(2em) .

Das Entfernen der Definition von Base würde es Leuten, die diese Syntax mögen, ermöglichen, interessantere Dinge damit zu tun.

Außer, dass es nicht verwendbar ist, da die einzige sichere Möglichkeit, es dann zu verwenden, Escher.|>(...) oder Lazy.|>(...) wäre.

Hypothetisch, wie würde man |> als Infix-Operator verwenden, wenn Sie zwei verschiedene Pakete verwenden, die es sowohl definieren als auch exportieren, vorausgesetzt, es ist nicht in Base definiert?

@kmsquire Es hängt vom Anwendungsfall ab. |> würde immer noch als Infix-Operator geparst werden, so wie es jetzt ist, es hätte nur keinen Wert in Base. Wenn Sie es in einem Makro verwenden, spielt es keine Rolle, wie ein bestimmtes Paket es definiert, da es einfach das erste Argument in einem Aufrufausdruck wird.

Nehmen Sie zum Beispiel <| , das als Infix-Operator geparst wird, aber keinen Wert hat. Auch wenn es undefiniert ist, haben wir es immer noch

julia> dump(:(a <| b))
Expr
  head: Symbol call
  args: Array{Any}((3,))
    1: Symbol <|
    2: Symbol a
    3: Symbol b
  typ: Any

Pakete können Methoden für Base.:(<|) definieren und exportieren, die verschiedene Dinge bedeuten, genau wie man es mit + tun kann.

Aber die Pakete, die nette Funktions-Pipings bieten, tun dies in Makros, ich nehme an, genau aus diesem Grund.

FWIW, kein Verkettungspaket müsste während der Auswertung |> verwenden, da während der Verkettung alles in einen Ausdruck gezippt wird. Ich würde mir vorstellen, dass wenn Pakete |> definieren, es genau die Definition in base sein wird. Obwohl sie wahrscheinlich stattdessen ein Verkettungsmakro verwenden sollten. Siehe DataFramesMeta für ein gutes Beispiel dafür, wie man eine Schnittstelle baut, die gut mit Verkettung funktioniert.

Wenn wir dies ablehnen, sollten wir dann auch * für die Zeichenfolgenverkettung ablehnen? Das hat ähnliche Probleme wie redundant mit string(a, b) und verstößt gegen das Prinzip der geringsten Überraschung, da a und b keine Zahlen sind.

Generell sollten wir wahrscheinlich alle Infix-Notationen ablehnen, da es verwirrend ist, mehrere Aufrufkonventionen wie *(a, b) vs. a * b zu haben – wir können unsere aktuellen 3 unterschiedlichen Syntaxen auf eine reduzieren und vollständige Konsistenz erreichen. Um Hässlichkeit zu vermeiden, könnten wir in Betracht ziehen, den Funktionsaufruf in die Klammern zu verschieben und vielleicht auch die überflüssigen Kommas zu entfernen.

|> würde immer noch als Infix-Operator geparst werden, so wie es jetzt ist, es hätte nur keinen Wert in Base. Wenn Sie es in einem Makro verwenden, spielt es keine Rolle, wie ein bestimmtes Paket es definiert

Immer noch nicht sicher, warum wir es aus Base entfernen müssen.

@bramtayl macht einen guten Punkt:

Ich könnte mir vorstellen, dass, wenn Pakete definieren, |> es genau die Definition ist, die Basis ist.

Und immer noch besteht die einzige Möglichkeit, mehr als ein Paket zu verwenden, das dies definiert, darin, es nicht infix zu verwenden.

Ich verstehe nicht, warum das Entfernen der Definition in Base erforderlich ist, damit |> in Makros verwendet werden kann.

Es ist nicht. Mein Punkt ist, dass |> innerhalb von Makros verwendet werden kann, unabhängig von der Situation in Base. Dasselbe gilt für jeden Operator, der entsprechend parst. Der Punkt des Vorschlags besteht darin, Base in Bezug auf Funktionsaufrufe selbstkonsistent zu machen, dann kann das Rohrleitungsverhalten durch Pakete erreicht werden. Ob die Pakete insbesondere |> verwenden, spielt keine Rolle; Sie könnten genauso gut <| oder buchstäblich jeden anderen Infix-Operator verwenden.

@ararslan richtig, das wollte ich nicht fragen, ich habe meinen Kommentar gleich danach aktualisiert, sorry.

Wie auch immer, ich verstehe das Gefühl "Basis in sich geschlossen in Bezug auf Funktionsaufrufe" nicht ganz. Anscheinend wird es dadurch nur schwieriger, |> in einem Nicht-Makro-Kontext zu verwenden. Ich persönlich glaube, dass |> für einen Neuling eine lohnende Sache ist, auch wenn es überraschend ist. Es spart zumindest Aufwand bei der REPL. Es macht Spaß, später zu erkennen, dass |> eine Funktion ist, genau wie jede andere Infix-Funktion, und die Lektion bekräftigt, dass Funktionen nur Werte sind.

Vielleicht nur etwas Formales: Bitte besprechen/entscheiden Sie Deprecierungen und/oder Syntaxänderungen zu Beginn eines Release-Zyklus, nicht am Ende. Derzeit verbringen alle Hauptentwickler und Paketverantwortlichen Zeit und Energie damit, 0.6 fertigzustellen, und sie haben vielleicht einfach keine Zeit, sich eine andere (gute) Idee auszudenken.

"Ich behaupte nicht, dass es nicht nützlich ist, sondern dass wir konsequent sein sollten"

Manchmal schlägt Nützlichkeit Konsistenz? Ich war mir der Inkonsistenz nicht bewusst, aber ich fand die |> -Syntax nützlich. Wenn es entfernt wird, habe ich nicht das Gefühl, etwas Greifbares gewonnen zu haben.

Eine Erklärung für meine Daumen-nach-unten-Abstimmung, wenn ich darf:

Vieles von dem, was derzeit in Base ist, könnte stattdessen in Paketen passieren. Sollten wir Wörterbücher in ein Paket verschieben? Vielleicht Listenoperationen wie Sortieren und Mischen? Inkassotätigkeiten etc.? Ich bin mir sicher, dass es lange und detaillierte Diskussionen darüber gegeben hat, was in Base enthalten sein sollte und was nicht, aber ich vermute, dass es drei Gründe gibt, warum einige Funktionen in Base enthalten sein könnten:
1) Diese Funktionalität ist notwendig, um andere Funktionen in base zu aktivieren.
2) Diese Funktionalität ist ein wesentlicher Bestandteil der Sprache, viele Julia-Programmierer und -Pakete werden sie verwenden, und daher ist es wünschenswert, eine einzige Implementierung/Syntax zu haben, auf die sich alle einigen, anstatt die Fragmentierung vieler Leute, die ihre eigene entwickeln.
3) Das Einbeziehen dieser Funktionalität in die Basis macht die Verwendung von "raw" Julia angenehmer oder lässt es sich umfassender anfühlen, was bei der Sprachevangelisation und -akzeptanz hilft.

Etwas wie sum trifft wahrscheinlich alle 3 Punkte, und ich würde argumentieren, dass Funktions-Piping den zweiten und dritten Punkt trifft:

Sowohl im ersten (gut geschriebenen) Vorschlag als auch in der Diskussion in diesem Thread ist ein gemeinsames Thema die Existenz mehrerer Pakete, die Pipe-ähnliche Funktionalität durch Makros bereitstellen: Lazy.jl, Pipe.jl, ChainMap.jl usw. Die Existenz von mehreren Paketen deutet stark darauf hin, dass viele Leute in der Community Piping als nützliches und wünschenswertes Feature empfinden, und die Anwesenheit dieser Pakete in diesem Diskussionsthread legt nahe, dass viele Leute hier die Verwendung von Piping verstehen und unterstützen.

Angesichts der Tatsache, dass Piping ein weit verbreitetes und beliebtes Feature in der Julia-Community und anderen Sprachen ist, scheinen sich die Leute sogar in dieser Diskussion darin einig zu sein, dass es viele Verwendungsmöglichkeiten hat, insbesondere bei der REPL (wo Julia glänzt), und dass es bereits eine Fragmentierung im Julia-Ökosystem gibt. .. meine Meinung ist nicht, dass es aus Base entfernt werden sollte, sondern dass die in Base verfügbare Piping-Syntax verbessert werden sollte, damit weniger Fragmentierung erforderlich ist. Verschiedene Pakete, die unterschiedliche Möglichkeiten zum Plotten bieten, scheinen in Ordnung zu sein; Verschiedene populäre Pakete, die verschiedene Möglichkeiten zum Anwenden von Funktionen anbieten, scheinen ziemlich beängstigend zu sein.

Ich argumentiere weiter, dass das Entfernen von Pipings aus Base, aber das Belassen des Infix-Operators ziemlich überraschend ist: In Julia können Sie keine eigenen Infix-Operatoren definieren, aber es gibt einen unbenutzten Infix-Operator |> , den Sie als definieren können du bitte? Wenn das eine gute Funktionalität ist, warum geben Sie uns nicht solide 10 oder 20 Infix-Operatoren, die wir nach Belieben definieren können?

Schließlich glaube ich, dass es natürlich ist, die Rohrleitungen genau beizubehalten, da sie sich von anderen Funktionsanwendungen unterscheiden. Es ist ein Feature, kein Fehler, das sich von anderen Konventionen zum Anwenden von Funktionen unterscheidet; Dieser Unterschied lässt es in einigen Anwendungsfällen glänzen. Und es gibt andere Fälle, in denen (etwas mit der Hand winkend) das Substantiv vor dem Verb steht, und viele davon sind genau syntaktischer Zucker in Fällen, in denen die Anwendung von Rohfunktionen unhandlich ist. Aus dem Kopf heraus setzt die Zuweisung x = 5 das Substantiv (Symbol x ) vor das Verb (an einen Wert binden). Ebenso für den Zugriff auf Felder vom Typ t.a anstelle von getfield . Und vor allem liest sich die Array-Indizierung z[5] wie „von z das 5. Element nehmen“ und ist im Allgemeinen natürlicher als getindex(z, 5) .

Wenn das eine gute Funktionalität ist, warum geben Sie uns nicht solide 10 oder 20 Infix-Operatoren, die wir nach Belieben definieren können?

Es gibt wahrscheinlich mehr als das, wenn man zusätzlich zu den nicht beanspruchten ASCII-Dateien wie <| , ++ , ...

Habe nicht den ganzen Thread gelesen, wollte es aber nur sagen
dass ich es liebe, pfeifen zu können. Ich würde für nützlich stimmen
Konsistenz jeden Tag.

Ich habe eine sehr leichte Präferenz, es zu behalten, aber es ist mir egal, solange es ein Infix-Operator bleibt. Ich habe das Gefühl, dass ich Funktions-Piping wahrscheinlich nicht verwenden würde, wenn es den Import eines Pakets beinhalten würde, was mir sagt, dass ich es nicht sehr schätze.

Abgesehen davon halte ich dieses Argument des „Prinzips der geringsten Überraschung“ nicht für überzeugend, da es einige Vermutungen über eine vielfältige Benutzerbasis anstellt. Für Muttersprachler von Subjekt-Objekt-Verb-Sprachen verstößt der größte Teil von Julias Syntax vermutlich gegen das Prinzip der geringsten Überraschung, und das Piping von Funktionen ist ziemlich bequem ...

Nicht den ganzen Thread lesen

😕

Ich liebe es, pfeifen zu können

Auch hier behaupte ich nicht, dass man nicht in der Lage sein sollte, Rohre zu leiten, sondern dass die Funktionalität stattdessen problemlos in einem der mehreren vorhandenen Rohrpakete enthalten sein könnte. Durch das Entfernen der Base-Pipe können Pakete ihre eigene Piping-Semantik leichter definieren, ohne sich an das halten oder konsistent bleiben zu müssen, was Base bietet.

In Julia können Sie keine eigenen Infix-Operatoren definieren

Das ist nicht wahr; Alles, was als Infix-Operator analysiert wird, kann definiert oder neu definiert werden. Wie Martinholters betonte, sind unter anderem <| und ++ ähnlich verfügbar.

Ich bin in dieser Hinsicht eher neutral, aber ich unterstütze das Gefühl, dass |> rückwärts von der normalen Funktionsaufrufsyntax ist, der springende Punkt ist. Selbst die größten Fans von Paspeln fragen (AFAIK) nicht nach zB sin <| x , weil das mit sin(x) wirklich überflüssig ist. |> ist für die Fälle, in denen es für die Augen und/oder das Gehirn einfacher ist, sich vorzustellen, dass Daten ohne viele Klammern von links nach rechts fließen.

Ich möchte, dass |> mächtiger wird, zB x |> f(_) + 2g(_) |> h etc. erlaubt und nicht nur ein Operator ist. Jedes Mal, wenn jemand x |> f so definiert hat, dass es etwas anderes als f(x) bedeutet, stolpert es mich wirklich, weil der springende Punkt des Operators, wie wir ihn verwendet haben, darin besteht, dass es sich um eine Aufrufsyntax einer anderen Ordnung handelt. Da wir call überladen können , sehe ich keinen guten Grund dafür, dass x |> f etwas anderes bedeutet.

@StefanKarpinski Leistungsfähigere Rohre können bereits über Makros erhalten werden. Siehe zum Beispiel Pipe.jl , das genau die von Ihnen beschriebene Syntax bereitstellt. Solange |> ein Operator ist (ich persönlich sehe |> nicht als Sonderfall an), können Makros jedes Piping-Trennzeichen verwenden, das Infix analysiert, auch wenn es kein Operator ist :call . Als Beispiel könnte man auf ähnliche Weise @~ verwenden, um zu pipen (zumindest zum Zeitpunkt dieses Schreibens). Dieses Maß an Flexibilität ist einer der Vorteile der Verwendung von Makros in Julia.

Wir könnten der Sprache die Funktionalität von Pipe.jl hinzufügen, und dann hätten Sie sie, ohne @pipe schreiben zu müssen.

Der Hauptgrund, |> abzulehnen, wäre, wenn wir die Syntax für einen anderen Zweck zurückerobern wollen, den die Leute viel besser mögen.

Ich denke, ich versuche zu argumentieren, dass Piping nicht Teil der Sprache sein muss, es kann (und tut es bereits) in einem Paket leben.

Aber wenn es nichts anderes gibt, wofür wir |> wollen, sehe ich wenig Schaden darin, seine (triviale) Definition allein zu lassen.

Ich glaube nicht, dass es derzeit Vorschläge zur Wiederverwendung |> in Base gibt. Mein Argument dafür, es nicht in Base zu definieren, ist, dass es uns mehr Konsistenz ohne Funktionsverlust gibt.

Würden Vorschläge für "leistungsstärkere Rohrleitungen" oder Paketimplementierungen einfacher gemacht, wenn man sich nicht um diese bestehende Definition kümmern oder sie umgehen müsste?

@ararslan "Das ist nicht wahr; alles, was als Infix-Operator analysiert wird, kann definiert oder neu definiert werden."

Von den manuellen Operatoren "&& und ||" werden sie analysiert, können aber nicht neu definiert werden (das ist eine gute Sache). Ich glaube, die einzigen Ausnahmen.

Die sogenannten "logischen Operatoren" && und || sind infix. [unäre binäre Beziehung] "Operator" ist IMHO der falsche Begriff für sie, da sie es nicht sind. Not ist ein ähnlicher Weg wie das logische bitweise & und | die eine Überladung zulassen (ich bin mir nicht sicher, ob das eine gute Wahl ist).

@PallHaraldsson Das sind Kontrollflüsse, keine Operatoren im gleichen Sinne wie & , | , + usw.

Versuchen wir bitte hier möglichst beim Thema zu bleiben.

@tkelman Das ist ein guter Punkt. Ich vermute jedoch, dass wir zukünftige Piping-Syntax abwärtskompatibel machen können. Wenn beispielsweise _ reserviert ist, dann kann |> eine besondere Bedeutung haben, wenn seine Argumente _ enthalten, und ansonsten dasselbe tun wie jetzt.

Es gibt noch ein weiteres Problem: Damit |> für Ihr Objekt funktioniert, definieren Sie |> oder den "Funktionsaufrufoperator" (dh fügen Sie ihm Methoden hinzu)? Es könnte sauberer sein, wenn |> eine eingebaute Syntax für Funktionsaufrufe wäre, um sicherzustellen, dass f(x) und x |> f immer gleich sind.

Der Konsens hier ist ganz klar dagegen, also werde ich fortfahren und das Thema schließen. Ich schätze die Diskussion, alle.

Ich weiß, dass dieses Thema geschlossen ist. Ich wollte nur "Danke" sagen, dass Sie den Operator behalten.