Julia: Funktionsanforderung: Operator hinzufügen, um Bruchlinien in der Matrixdefinition zuzulassen

A = [1 2 3 4 5  #=
  =# 6 7 8 9 10]

funktioniert auch und erfordert nicht die Zuweisung eines zusätzlichen temporären [5] Arrays. Mehrzeilige Kommentare (#69) FTW!

(Obwohl ich ehrlich gesagt das Problem mit 150 Floats in einer Zeile nicht sehe. Haben Editoren heutzutage keine horizontalen Bildlaufleisten? Wenn Sie eine 150 × 150-Matrix in Ihrem Code haben, wird es nur eine Wand aus 22500 Zahlen sein Wie auch immer, und Scrollen scheint eine gute Möglichkeit zu sein, es in Ihrem Code zu betrachten. Sie können auch in Ihrem Editor die weiche Zeilenumbruchfunktion aktivieren, wenn Sie kurze Zeilen mögen.)

Ich weiß nicht, ob die zwei Punkte .. irgendwo verwendet werden, aber ich denke, es ist sehr geeignet für die Zeilenfortsetzung, oder \dots ( … ), -- usw. Ein Vergleich verschiedener Sprachen ist hier .

Hallo @stevengj ,

Ich bin es immer noch gewohnt, meinen Code in Spalte 80 einzuschließen. IMHO wird der Code viel lesbarer und einfacher zu bearbeiten, da Sie Ihren Editor in zwei Teile aufteilen können und trotzdem den gesamten Code ohne Scrollen sehen können.

Abgesehen davon haben alle Sprachen, an die ich mich erinnere, einen Mechanismus zur Zeilenfortsetzung. Dies verbessert in einigen Fällen die Lesbarkeit des Codes wirklich. Ich denke, Julia hätte das auch tun sollen. Natürlich können Sie alles so machen, wie es heute ist, aber mit einer solchen Funktion werden wir, denke ich, etwas klarer schreiben können.

Kann Ihr Redakteur bei Spalte 80 nicht Soft Wrapping durchführen, wenn Sie das bevorzugen?

(Bei den meisten Julia-Sprachen können Sie Zeilenumbrüche ohne Hacks einfügen, z. B. nach einem Paren-, Komma- oder Binäroperator. Literale Matrizen sind eine seltene Ausnahme.)

Zwei Punkte (..) und Ellipsen (…) werden bereits als binäre Operatoren geparst, und im Allgemeinen sind Operatoren viel nützlicher als eine Fortsetzungssyntax, die nur selten vorkommen würde (und bereits mit #= =# möglich ist).

Hallo @stevengj

Ich verwende vim (eigentlich neovim), ich kann Soft Wrapping durchführen, aber normalerweise werden Dinge wie mehrere Zeilencursor und Makros unterbrochen. Deshalb ziehe ich es immer vor, Linien tatsächlich zu unterbrechen.

Sie können dieses Problem jedoch gerne schließen, wenn Sie der Meinung sind, dass eine solche Funktion nicht gut mit dem Julia-Sprachdesign zusammenpasst.

Ich denke, was wir wirklich wollen, ist etwas Allgemeineres: eine Möglichkeit, jede Zeile fortzusetzen, die nicht spezifisch für die Matrixsyntax ist. Das Beste, was mir eingefallen ist, ist \ als letztes Nicht-Leerzeichen in einer Zeile, was eine bahnbrechende Änderung wäre, da dies derzeit gültige, aber seltsame Syntax ist:

x = y \
    z

Wir könnten sogar weiterhin diese Verwendung von \ in nicht-weißraumsensitiven Kontexten unterstützen, da y z eine ungültige Syntax ist, aber das ist wahrscheinlich etwas zu clever. Ich bin mir nicht sicher, ob sich das lohnt, aber die meisten Sprachen haben eine Möglichkeit, Zeilen fortzusetzen. Der Trick mit mehrzeiligen Kommentaren funktioniert auch, ist aber etwas ausführlich.

Sehr brechend...

julia> 2\
       10
5.0

julia> 2#=
       =#10
20

Es ist definitiv kaputt, aber ich wäre überrascht, wenn \ so oft verwendet wird.

Vielleicht #\ ? Sicher, einem zuvor ignorierten Kommentar ein neues Verhalten zuzuordnen, ist ebenfalls kaputt, aber #\ als Kommentar zu haben ist wahrscheinlich noch seltener als ein Zeilenumbruch nach \ (als Operator verwendet).

Die Tatsache, dass mehrzeilige Kommentare eine relativ ausführliche Möglichkeit sind, dies zu tun, ist meiner Meinung nach eine gute Sache, um die Leute davon abzuhalten, sie beiläufig zu verwenden. Python hat eine Zeilenfortsetzung mit umgekehrtem Schrägstrich, wird aber

Hallo @stevengj ,

Ich bin mir nicht sicher, warum Leute davon abgehalten werden sollten, Zeilenumbrüche zu verwenden. Siehe zum Beispiel diesen Code:

            xndot = d2201 * sin(2ω + xli  - G22) +
                    d2211 * sin(   + xli  - G22) +
                    d3210 * sin(+ω + xli  - G32) -
                    d3222 * sin(-ω + xli  - G32) -
                    d5220 * sin(+ω + xli  - G52) +
                    d5232 * sin(-ω + xli  - G52) +
                    d4410 * sin(2ω + 2xli - G44) -
                    d4422 * sin(     2xli - G44) +
                    d5421 * sin(+ω + 2xli - G54) +
                    d5433 * sin(-ω + 2xli - G54)

IMHO, das Betriebszeichen am Ende ist nicht so gut wie am Anfang:

            xndot = + d2201 * sin(2ω + xli  - G22) \
                    + d2211 * sin(   + xli  - G22) \
                    + d3210 * sin(+ω + xli  - G32) \
                    - d3222 * sin(-ω + xli  - G32) \
                    - d5220 * sin(+ω + xli  - G52) \
                    + d5232 * sin(-ω + xli  - G52) \
                    + d4410 * sin(2ω + 2xli - G44) \
                    - d4422 * sin(     2xli - G44) \
                    + d5421 * sin(+ω + 2xli - G54) \
                    + d5433 * sin(-ω + 2xli - G54)

Es fühlt sich für mich einfach viel natürlicher an. Auch hier handelt es sich um eine kosmetische Änderung, jeder wird eine andere Meinung dazu haben. Die Frage ist: Wird es dem Sprachdesign in irgendeiner Weise schaden?

Scheint einfacher, in diesem Fall einfach ein zusätzliches Paar einschließender Klammern zu setzen.

Ja, es ist machbar. Aber auch hier ist es IMHO nicht üblich. Nehmen wir an, jemand sieht das:

            xndot = (+ d2201 * sin(2ω + xli  - G22)
                     + d2211 * sin(   + xli  - G22)
                     + d3210 * sin(+ω + xli  - G32)
                     - d3222 * sin(-ω + xli  - G32)
                     - d5220 * sin(+ω + xli  - G52)
                     + d5232 * sin(-ω + xli  - G52)
                     + d4410 * sin(2ω + 2xli - G44)
                     - d4422 * sin(     2xli - G44)
                     + d5421 * sin(+ω + 2xli - G54) 
                     + d5433 * sin(-ω + 2xli - G54))

Aus mathematischer Sicht haben diese Klammern keine Bedeutung. Jemand könnte sie versehentlich entfernen, Julia zeigt keine Warnungen an und der Code ist völlig falsch.

Das Beste, was mir eingefallen ist, ist \ als letztes Nicht-Leerzeichen in einer Zeile, was eine bahnbrechende Änderung wäre, da dies derzeit gültige, aber seltsame Syntax ist

Wie wäre es mit # für den gleichen Zweck? Die Interpretation ist, dass Sie den Zeilenumbruch auskommentieren. (Danke @oxinabox, dass LaTeXs Verwendung von % als Kommentar-/ Zeilenfortsetzung erwähnt hast )

Nun, aus meiner Sicht sollte ein # am Ende der Zeile ohne Zeichenfolgen sehr nett sein und scheint weniger Dinge zu zerstören.

Das einzige potenzielle Problem, das ich hier sehe, ist, dass von

a=1 #because reasons
 +2

zu

a=1 #
 +2

erzeugt unterschiedliche Ergebnisse. Dies ist aber wahrscheinlich egal.

Was ist mit etwas, das Julia nicht verwendet, wie \\ ? Ist es zu hässlich?

Ich würde erwarten, dass ich im Latex-Stil "Das Neue kommentieren mag" Dinge kaputt machen würde.

Es sei denn, es wurde nur auf ein # ohne jegliche Nicht-Leerzeichen danach beschränkt.
Zum Beispiel:

colors = [ 0.5 0.2 0.1 0.9 # Red
                0.4 0.4 0.1 0.6 # Green
                0.1 0.2 0.1 0.1] # Blue

In LaTeX, das keine neuen Zeilen enthält.
Und wenn sich ein leerer Kommentar anders verhält als ein nicht leerer, klingt das komisch.

Ich habe es eigentlich nicht für Julia vorgeschlagen.
Ich denke, \\ wäre viel weniger verwirrend.
Aber ich denke, @stevengj Lösung eines mehrzeiligen Kommentars könnte am schönsten sein. Es wird die neue Zeile sehr explizit auskommentiert

Obwohl die Erstellung riesiger mehrzeiliger Literale eine ziemliche Nische zu sein scheint.
Noch mehr, als Literale für Array{T, 3} .

Man sollte sie genauso effizient konstruieren können, indem man die Befehle vect und cat , auf die das Literal ohnehin absinkt.

Ich denke, der Vorschlag war, nur ein # gefolgt von einem Zeilenumbruchzeichen (oder wahrscheinlich nur Leerzeichen) zu verwenden.

Ja, ich meinte, @StefanKarpinskis Vorschlag einer besonderen Behandlung von # am Ende einer Zeile zu machen, definitiv nicht den Fall mitzählen , in dem es andere Nicht-Leerzeichen nach dem # . Vielleicht war der LaTeX-Vergleich mehr verwirrend als klarstellend für das, was ich sagen wollte.

# kooptieren scheint mir riskant. Ich habe manchmal # s in meinem Code verstreut, aus Gründen, an die ich mich nicht mehr erinnere, Kommentare, bei denen ich meine Meinung geändert habe usw. Es wäre sehr einfach, versehentlich ein nachgestelltes # zu entfernen

Ich vermisse gelegentlich einen Zeilenfortsetzungsoperator, aber ich würde es vorziehen, wenn er sehr offensichtlich ist, wie \ oder ... . Die #= oder [] wirken ein bisschen zu sehr wie ein _Trick_.

(Wenn von der Verwendung abgeraten werden soll, würde vielleicht etwas etwas Hässliches wie \\\ funktionieren?)

Es ist auch ganz normal für mich, Kommentare nach einem Zeilenfortsetzungsoperator zu setzen, daher möchte ich mich nicht darauf verlassen müssen, dass es das letzte Nicht-Leerzeichen in der Zeile ist.

Ich bin mir nicht sicher, ob sie bereits an anderer Stelle verwendet werden oder für benutzerspezifische Operatoren reserviert sein sollten, aber einer dieser Unicode-Pfeile könnte ansprechende, intuitive Optionen für die explizite Zeilenfortsetzung bieten:

↩ , ⬎ oder ⤸

(zugänglich gemacht, zB mit einem sinnvollen, tabellarischen Alias, wie \continueline )

Ich denke, es ist ein Glück, dass #= =# funktioniert und wir sollten es dabei belassen.

Ich stimme nicht zu, dass Backslashes am Ende jeder Zeile irgendwie besser ist, als Klammern hinzuzufügen oder einfach nur die Operatoren an das Ende der Zeile zu setzen. Ich glaube auch nicht, dass der Missbrauch von Backslash oder # eine Verbesserung sein wird; das würde nur Überraschungen hinzufügen. Wenn wir etwas mit mehreren Zeichen verwenden würden, wäre dies keine große Verbesserung gegenüber #= =# .

Ich stimme nicht zu, dass Backslashes am Ende jeder Zeile irgendwie besser ist, als Klammern hinzuzufügen oder einfach nur die Operatoren an das Ende der Zeile zu setzen.

Der Grund, warum dieses Problem geöffnet wurde, war, dass keines dieser für Matrixliterale funktioniert. Trotzdem stimme ich zu, dass wir wahrscheinlich nichts dafür tun sollten, da #= =# bereits funktioniert.

Nun, da ich gesehen habe, dass Sie #= =# für die Zeilenfortsetzung verwenden können, ist dies absolut sinnvoll. Aber wenn ich ehrlich bin, wäre ich alleine sicher nicht zu diesem Schluss gekommen.

Der vielleicht beste Weg ist, der Dokumentation und dem Julia-Styleguide etwas hinzuzufügen, das besagt, dass die Zeilenfortsetzung über #= =# .

Um die Diskussion zu beenden, @StefanKarpinski , denken Sie, dass selbst der von @thchr vorgeschlagene

A = [1 2 3 4 5 ⤸
     6 7 8 9 10]

Weniger ausführlich als #= =# und optisch ansprechend.

Das liest sich zugegebenermaßen schön. Ein Nebeneffekt ist, dass dies eine kanonische Methode zum Drucken von Code mit langen Zeilen auf Displays mit fester Breite ergeben würde, sodass die Ausgabe gültigen Code bildet.

Wir analysieren jedoch bereits viele Unicode-Pfeile als binäre Operatoren.

Ich vermute, wir könnten einen entbehren.

Gute Möglichkeiten IMHO:

⤸ (2938) ↩ (8617) ↵ (8629) 

Vielleicht ist es an der Zeit, Whitespace zu einem Operator zu machen, und wir können ihn in großen Matrixkontexten mit Cassette überladen. Glücklicherweise hat Bjarne Stroustrup bereits die harte Designarbeit für uns erledigt – http://www.stroustrup.com/whitespace98.pdf

Wenn wir etwas mit mehreren Zeichen verwenden würden, wäre dies keine große Verbesserung gegenüber #= =# .

Dagegen möchte ich drei Argumente anführen.

Erstens kann dies mit einem Kommentar verwechselt werden. Selbst wenn ich das weiß, registriert mein Gehirn "Kommentar".

Zweitens müssen Sie es auf zwei Zeilen setzen, nicht nur auf eine. (Wie wird dies mit der Einrückung interagieren?)

Drittens ist es eine kompliziertere Kombination von Tastendrücken (auf meinem Computer ist es shift-3 shift-0 enter shift-0 shift-3 ). Ich vermute, dass eine Art Tastenkombination verwendet werden könnte. \\ ist im Gegensatz dazu zwei schnelles Drücken derselben Taste (gefolgt von enter .)

Dreieinhalb: IMHO sieht es etwas umständlich aus und fühlt sich an wie ein Trick.

Auch wenn das \\ nicht akzeptiert wird, weil es vielleicht für die zukünftige Verwendung "reserviert" wird, finde ich den @thchr- Vorschlag wirklich sehr schön. Schau, wie es sein wird:

            xndot = + d2201 * sin(2ω + xli  - G22) ⤸
                    + d2211 * sin(   + xli  - G22) ⤸
                    + d3210 * sin(+ω + xli  - G32) ⤸
                    - d3222 * sin(-ω + xli  - G32) ⤸
                    - d5220 * sin(+ω + xli  - G52) ⤸
                    + d5232 * sin(-ω + xli  - G52) ⤸
                    + d4410 * sin(2ω + 2xli - G44) ⤸
                    - d4422 * sin(     2xli - G44) ⤸
                    + d5421 * sin(+ω + 2xli - G54) ⤸
                    + d5433 * sin(-ω + 2xli - G54)

Außerdem wird niemand dazu gezwungen und es wird nichts kaputt gehen. Aber ich bin mir sicher, dass es dafür gute Anwendungsfälle geben wird (die großen Matrizen, die mich dazu gebracht haben, dieses Problem zu eröffnen, sind einer):

pd = [
     1.09979E+00 -4.88060E-02 -1.97501E-01 -9.10280E-02 -6.96558E-03 ⤸ 
     2.42136E-02  3.91333E-01 -7.20068E-03 -3.22718E-02  1.41508E+00 ⤸
     1.68194E-01  1.85282E-02  1.09384E-01 -7.24282E+00  0.00000E+00 ⤸
     2.96377E-01 -4.97210E-02  1.04114E+02 -8.61108E-02 -7.29177E-04 ⤸
     1.48998E-06  1.08629E-03  0.00000E+00  0.00000E+00  8.31090E-02 ⤸
     1.12818E-01 -5.75005E-02 -1.29919E-02 -1.78849E-02 -2.86343E-06 ⤸
     0.00000E+00 -1.51187E+02 -6.65902E-03  0.00000E+00 -2.02069E-03 ⤸
     0.00000E+00  0.00000E+00  4.32264E-02 -2.80444E+01 -3.26789E-03 ⤸
     2.47461E-03  0.00000E+00  0.00000E+00  9.82100E-02  1.22714E-01 ⤸
    -3.96450E-02  0.00000E+00 -2.76489E-03  0.00000E+00  1.87723E-03 ⤸
    -8.09813E-03  4.34428E-05 -7.70932E-03  0.00000E+00 -2.28894E-03 ⤸
    -5.69070E-03 -5.22193E-03  6.00692E-03 -7.80434E+03 -3.48336E-03 ⤸
    -6.38362E-03 -1.82190E-03  0.00000E+00 -7.58976E+01 -2.17875E-02 ⤸
    -1.72524E-02 -9.06287E-03  0.00000E+00  2.44725E-02  8.66040E-02 ⤸
     1.05712E-01  3.02543E+04  0.00000E+00  0.00000E+00  0.00000E+00 ⤸
    -6.01364E+03 -5.64668E-03 -2.54157E-03  0.00000E+00  3.15611E+02 ⤸
    -5.69158E-03  0.00000E+00  0.00000E+00 -4.47216E-03 -4.49523E-03 ⤸
     4.64428E-03  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00 ⤸
     4.51236E-02  2.46520E-02  6.17794E-03  0.00000E+00  0.00000E+00 ⤸
    -3.62944E-01 -4.80022E-02 -7.57230E+01 -1.99656E-03  0.00000E+00 ⤸
    -5.18780E-03 -1.73990E-02 -9.03485E-03  7.48465E-03  1.53267E-02 ⤸
     1.06296E-02  1.18655E-02  2.55569E-03  1.69020E-03  3.51936E-02 ⤸
    -1.81242E-02  0.00000E+00 -1.00529E-01 -5.10574E-03  0.00000E+00 ⤸
     2.10228E-03  0.00000E+00  0.00000E+00 -1.73255E+02  5.07833E-01 ⤸
    -2.41408E-01  8.75414E-03  2.77527E-03 -8.90353E-05 -5.25148E+00 ⤸
    -5.83899E-03 -2.09122E-02 -9.63530E-03  9.77164E-03  4.07051E-03 ⤸
     2.53555E-04 -5.52875E+00 -3.55993E-01 -2.49231E-03  0.00000E+00 ⤸
     0.00000E+00  2.86026E+01  0.00000E+00  3.42722E-04  0.00000E+00 ⤸
     0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00 ⤸
     0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00;
     1.02315E+00 -1.59710E-01 -1.06630E-01 -1.77074E-02 -4.42726E-03 ⤸
     3.44803E-02  4.45613E-02 -3.33751E-02 -5.73598E-02  3.50360E-01 ⤸
     6.33053E-02  2.16221E-02  5.42577E-02 -5.74193E+00  0.00000E+00 ⤸
     1.90891E-01 -1.39194E-02  1.01102E+02  8.16363E-02  1.33717E-04 ⤸
     6.54403E-06  3.10295E-03  0.00000E+00  0.00000E+00  5.38205E-02 ⤸
     ...

Anstatt von

pd = [
     1.09979E+00 -4.88060E-02 -1.97501E-01 -9.10280E-02 -6.96558E-03 #= 
 =#  2.42136E-02  3.91333E-01 -7.20068E-03 -3.22718E-02  1.41508E+00 #=
 =#  1.68194E-01  1.85282E-02  1.09384E-01 -7.24282E+00  0.00000E+00 #=
 =#  2.96377E-01 -4.97210E-02  1.04114E+02 -8.61108E-02 -7.29177E-04 #=
 =#  1.48998E-06  1.08629E-03  0.00000E+00  0.00000E+00  8.31090E-02 #=
 =#  1.12818E-01 -5.75005E-02 -1.29919E-02 -1.78849E-02 -2.86343E-06 #=
 =#  0.00000E+00 -1.51187E+02 -6.65902E-03  0.00000E+00 -2.02069E-03 #=
 =#  0.00000E+00  0.00000E+00  4.32264E-02 -2.80444E+01 -3.26789E-03 #=
 =#  2.47461E-03  0.00000E+00  0.00000E+00  9.82100E-02  1.22714E-01 #=
 =# -3.96450E-02  0.00000E+00 -2.76489E-03  0.00000E+00  1.87723E-03 #=
 =# -8.09813E-03  4.34428E-05 -7.70932E-03  0.00000E+00 -2.28894E-03 #=
 =# -5.69070E-03 -5.22193E-03  6.00692E-03 -7.80434E+03 -3.48336E-03 #=
 =# -6.38362E-03 -1.82190E-03  0.00000E+00 -7.58976E+01 -2.17875E-02 #=
 =# -1.72524E-02 -9.06287E-03  0.00000E+00  2.44725E-02  8.66040E-02 #=
 =#  1.05712E-01  3.02543E+04  0.00000E+00  0.00000E+00  0.00000E+00 #=
 =# -6.01364E+03 -5.64668E-03 -2.54157E-03  0.00000E+00  3.15611E+02 #=
 =# -5.69158E-03  0.00000E+00  0.00000E+00 -4.47216E-03 -4.49523E-03 #=
 =#  4.64428E-03  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00 #=
 =#  4.51236E-02  2.46520E-02  6.17794E-03  0.00000E+00  0.00000E+00 #=
 =# -3.62944E-01 -4.80022E-02 -7.57230E+01 -1.99656E-03  0.00000E+00 #=
 =# -5.18780E-03 -1.73990E-02 -9.03485E-03  7.48465E-03  1.53267E-02 #=
 =#  1.06296E-02  1.18655E-02  2.55569E-03  1.69020E-03  3.51936E-02 #=
 =# -1.81242E-02  0.00000E+00 -1.00529E-01 -5.10574E-03  0.00000E+00 #=
 =#  2.10228E-03  0.00000E+00  0.00000E+00 -1.73255E+02  5.07833E-01 #=
 =# -2.41408E-01  8.75414E-03  2.77527E-03 -8.90353E-05 -5.25148E+00 #=
 =# -5.83899E-03 -2.09122E-02 -9.63530E-03  9.77164E-03  4.07051E-03 #=
 =#  2.53555E-04 -5.52875E+00 -3.55993E-01 -2.49231E-03  0.00000E+00 #=
 =#  0.00000E+00  2.86026E+01  0.00000E+00  3.42722E-04  0.00000E+00 #=
 =#  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00 #=
 =#  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00;
     1.02315E+00 -1.59710E-01 -1.06630E-01 -1.77074E-02 -4.42726E-03 #=
 =#  3.44803E-02  4.45613E-02 -3.33751E-02 -5.73598E-02  3.50360E-01 #=
 =#  6.33053E-02  2.16221E-02  5.42577E-02 -5.74193E+00  0.00000E+00 #=
 =#  1.90891E-01 -1.39194E-02  1.01102E+02  8.16363E-02  1.33717E-04 #=
 =#  6.54403E-06  3.10295E-03  0.00000E+00  0.00000E+00  5.38205E-02 #=
     ...

In dem Maße, dass eine solche Zahlenwand jemals "schön aussehen" kann, sieht es für mich viel schöner aus, jede Reihe auf eine einzige Zeile zu setzen. Zumindest kann ich so erkennen, wie viele Zeilen die Matrix hat und ob die Zeilen gleich lang sind.

pd = [ 1.09979E+00 -4.88060E-02 -1.97501E-01 -9.10280E-02 -6.96558E-03 2.42136E-02  3.91333E-01 -7.20068E-03 -3.22718E-02  1.41508E+00 1.68194E-01  1.85282E-02  1.09384E-01 -7.24282E+00  0.00000E+00 2.96377E-01 -4.97210E-02  1.04114E+02 -8.61108E-02 -7.29177E-04 1.48998E-06  1.08629E-03  0.00000E+00  0.00000E+00  8.31090E-02 1.12818E-01 -5.75005E-02 -1.29919E-02 -1.78849E-02 -2.86343E-06 0.00000E+00 -1.51187E+02 -6.65902E-03  0.00000E+00 -2.02069E-03 0.00000E+00  0.00000E+00  4.32264E-02 -2.80444E+01 -3.26789E-03 2.47461E-03  0.00000E+00  0.00000E+00  9.82100E-02  1.22714E-01 -3.96450E-02  0.00000E+00 -2.76489E-03  0.00000E+00  1.87723E-03 -8.09813E-03  4.34428E-05 -7.70932E-03  0.00000E+00 -2.28894E-03 -5.69070E-03 -5.22193E-03  6.00692E-03 -7.80434E+03 -3.48336E-03 -6.38362E-03 -1.82190E-03  0.00000E+00 -7.58976E+01 -2.17875E-02 -1.72524E-02 -9.06287E-03  0.00000E+00  2.44725E-02  8.66040E-02 1.05712E-01  3.02543E+04  0.00000E+00  0.00000E+00  0.00000E+00 -6.01364E+03 -5.64668E-03 -2.54157E-03  0.00000E+00  3.15611E+02 -5.69158E-03  0.00000E+00  0.00000E+00 -4.47216E-03 -4.49523E-03 4.64428E-03  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00 4.51236E-02  2.46520E-02  6.17794E-03  0.00000E+00  0.00000E+00 -3.62944E-01 -4.80022E-02 -7.57230E+01 -1.99656E-03  0.00000E+00 -5.18780E-03 -1.73990E-02 -9.03485E-03  7.48465E-03  1.53267E-02 1.06296E-02  1.18655E-02  2.55569E-03  1.69020E-03  3.51936E-02 -1.81242E-02  0.00000E+00 -1.00529E-01 -5.10574E-03  0.00000E+00 2.10228E-03  0.00000E+00  0.00000E+00 -1.73255E+02  5.07833E-01 -2.41408E-01  8.75414E-03  2.77527E-03 -8.90353E-05 -5.25148E+00 -5.83899E-03 -2.09122E-02 -9.63530E-03  9.77164E-03  4.07051E-03 2.53555E-04 -5.52875E+00 -3.55993E-01 -2.49231E-03  0.00000E+00 0.00000E+00  2.86026E+01  0.00000E+00  3.42722E-04  0.00000E+00 0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00 0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00
       1.02315E+00 -1.59710E-01 -1.06630E-01 -1.77074E-02 -4.42726E-03 3.44803E-02  4.45613E-02 -3.33751E-02 -5.73598E-02  3.50360E-01 6.33053E-02  2.16221E-02  5.42577E-02 -5.74193E+00  0.00000E+00 1.90891E-01 -1.39194E-02  1.01102E+02  8.16363E-02  1.33717E-04 6.54403E-06  3.10295E-03  0.00000E+00  0.00000E+00  5.38205E-02 ...
       ...

Ich finde es großartig, dass es eine offensichtliche Möglichkeit gibt, Ausdrücke zu schreiben, die mehrere Zeilen überschreiten, da Konsistenz im gesamten Ökosystem wichtiger ist als Flexibilität bei dieser Art der Formatierung.

Dies deutet darauf hin, dass wir die Dinge so lassen, wie sie sind, mit Ausnahme einer Sache: In Kontexten, in denen Whitespace von Bedeutung ist (Makros, aber auch Matrixkonstruktion), gibt es derzeit keine offensichtlichen Möglichkeiten, Zeilen fortzusetzen. Der mehrzeilige Kommentar-Hack ist clever, aber auch hässlich, IMO.

Wir können beides gleichzeitig lösen, indem wir eine Zeilenfortsetzung hinzufügen, die nur in space-sensitive Parsing-Kontexten gültig ist:

# Valid - space sensitive context
<strong i="10">@info</strong> "A message which could be rather long"  ⤸
      my_variable my_variable2                ⤸
      some_other_variable

# Invalid - there should only be one way to do this
x = some_variable ⤸
    + other_variable
# Valid - the current, perfectly good convention for writing this
x = some_variable +
    other_variable

Ich habe Unicode ⤸ für die Zeilenfortsetzung im cjf/line-continuation Zweig implementiert. Dies ist eine einfachere Version, die nicht auf platzkritische Kontexte beschränkt ist, aber das sollte mit ein wenig Umordnung einfach sein.

Es wäre wirklich gut, einen expliziten kombinierten Spaltentrennungs- und Zeilenfortsetzungsoperator zu haben. Es würde das Problem von OP lösen und die Lesbarkeit von Matrixausdrücken mit Formeln verbessern. Mock-Beispiel mit | ,

       [ x .+ 1 | 3*(x .+ 2) |
        12 + x | -x ]

Warum ist mehr als ein Zeilenfortsetzungszeichen erforderlich?

Um einen konkreten Vorschlag zu haben, habe ich dazu eine PR gemacht - siehe #29273

@c42f , IMHO, ich denke, es wird etwas verwirrend sein, das

Stefan: Nur aus Gründen der Lesbarkeit. Dies würde nur vorschlagen, Zeilenfortsetzungszeichen innerhalb einer Zeile zu erlauben, die Feldtrennung in einem durch Leerzeichen getrennten Kontext hervorzuheben und zu erzwingen.

@ronisbr die Tatsache, dass es in den meisten Ausdrücken nur eine offensichtliche Möglichkeit gibt, Zeilen fortzusetzen, wie zum Beispiel

x = a +
    b +
    c

ist für mich ziemlich ansprechend und das wollte ich nicht ändern.

Damit dies auch geschrieben werden kann als

x =   a  ⤸
    + b  ⤸
    + c

führt nur unnötige Variationen IMO ein.

Die Sprache hat bereits das Konzept von "space-sensitiven" Kontexten, in denen die Parsing-Regeln unterschiedlich sind, und das fügt sich gut ein.

Hallo Leute!

Können wir nun, da wir 1.1 haben, diese Funktion für 1.2 besprechen? Können wir zumindest entscheiden, ob dies irgendwann ein neues Feature wird oder dieses Problem geschlossen werden soll?

cc @JeffBezanson , auch bekannt als Syntax-Zar.

Als mehrzeilige Kommentare gefunden zu haben , indem vorgeschlagen @stevengj vollkommen ausreichend für diesen Zweck (und im Allgemeinen), frage ich mich , wenn wir genau dies im Handbuch erwähnen könnten und somit das Problem zu beheben , um die Sprache ohne Änderung. Wenn ja, mache ich gerne eine PR an den entsprechenden Stellen (eine für Matrizen, eine als allgemeine Beratung).

Mir ist klar, dass einige Sprachen dafür eine spezielle Syntax haben, und das ist gelegentlich nützlich. Ich glaube jedoch nicht, dass das Schreiben von superlangen Zeilen oder das Einfügen großer wörtlicher Matrizen in den Quelltext zu einer Gewohnheit werden sollten, die durch die Sprache gefördert wird, und nicht zu etwas, für das wir nur in seltenen Fällen Unterstützung haben.

Ich stimme zu, dass der Fall für mehrzeilige Matrixumbrüche ausreichend ungewöhnlich ist, um durch die Verwendung von #= =# abgedeckt zu werden, und es wäre es wert, diese Option für die Zeilenfortsetzung zu dokumentieren. Für mehrzeilige Makroaufrufe verwende ich diese Syntax, finde sie aber immer noch hässlich und umständlich.

Für mehrzeilige Makroaufrufe können Sie Klammern verwenden.

Ich kenne die Option, Parens für Makros zu verwenden, aber ich finde sie unbefriedigend, wie ich zuvor beschrieben habe. Durch die Verwendung von Klammern und Kommas unterscheidet sich der Makroaufruf nämlich sehr visuell von der Art und Weise, wie Makros in den meisten Juila-Codes "normalerweise aussehen". Code, der anders aussieht, ist schwerer zu lesen.