Julia: Demande de fonctionnalité : ajouter un opérateur pour autoriser les lignes de rupture dans la définition de la matrice

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

fonctionne également et n'implique pas l'allocation d'un tableau [5] supplémentaire temporaire. Commentaires multilignes (#69) FTW!

(Bien qu'honnêtement, je ne vois pas le problème d'avoir 150 flottants sur une ligne. Les éditeurs n'ont-ils pas de barres de défilement horizontales de nos jours? Si vous avez une matrice 150 × 150 dans votre code, ce sera juste un mur de 22 500 nombres de toute façon, et le défilement semble un moyen aussi efficace que n'importe quel autre de le regarder dans votre code. Vous pouvez également activer l'habillage logiciel dans votre éditeur si vous aimez les lignes courtes.)

Je ne sais pas si les deux points .. sont utilisés quelque part, mais je pense que c'est très approprié pour la continuation de ligne, ou \dots ( … ), -- , etc. Une comparaison des différentes langues est ici .

Salut @stevengj ,

Je suis toujours habitué à envelopper mon code à la colonne 80. À mon humble avis, le code devient beaucoup plus lisible et plus facile à utiliser car vous pouvez diviser votre éditeur en deux parties et toujours voir tout le code sans faire défiler.

En plus de cela, toutes les langues dont je me souviens ont un mécanisme de continuation de ligne. Cela améliore vraiment la lisibilité du code dans certaines occasions. Je pense que Julia aurait dû aussi. Bien sûr, vous pouvez tout faire comme c'est le cas aujourd'hui, mais avec une telle fonctionnalité, je pense que nous pourrons écrire un peu plus clairement.

Votre éditeur ne peut-il pas effectuer un habillage souple à la colonne 80 si c'est ce que vous préférez ?

(Pour la plupart du langage Julia, vous pouvez insérer des sauts de ligne sans hacks, par exemple après n'importe quelle parenthèse, virgule ou opérateur binaire. Les matrices littérales sont une rare exception.)

Deux points (..) et des ellipses (…) sont déjà analysés comme des opérateurs binaires, et en général les opérateurs sont bien plus utiles qu'une syntaxe de continuation qui n'apparaîtrait que rarement (et est déjà possible avec #= =#).

Salut @stevengj

J'utilise vim (en fait neovim), je peux faire du soft wrap, mais cela casse généralement des choses comme les curseurs et les macros à plusieurs lignes. C'est pourquoi je préfère toujours casser les lignes.

Cependant, n'hésitez pas à fermer ce problème si vous pensez que cette fonctionnalité ne fonctionne pas bien avec la conception du langage Julia.

Je pense que ce que nous voudrions vraiment, c'est quelque chose de plus général : un moyen de continuer n'importe quelle ligne, non spécifique à la syntaxe matricielle. La meilleure chose que j'ai pu trouver est \ comme dernier espace non blanc sur une ligne, ce qui serait un changement radical car c'est une syntaxe actuellement valide mais étrange :

x = y \
    z

Nous pourrions même continuer à prendre en charge cette utilisation de \ dans des contextes non sensibles aux espaces blancs car y z est une syntaxe invalide mais c'est probablement un peu trop intelligent. Je ne suis pas sûr que cela en vaille la peine, mais la plupart des langues ont un moyen de continuer les lignes. L'astuce du commentaire multiligne fonctionne aussi mais est un peu verbeuse.

Très cassant...

julia> 2\
       10
5.0

julia> 2#=
       =#10
20

C'est définitivement cassé mais je serais surpris si \ est utilisé comme ça souvent.

Peut-être #\ ? Bien sûr, associer un nouveau comportement à un commentaire précédemment ignoré est également rompu, mais avoir #\ comme commentaire est probablement encore moins courant que de rompre une ligne après \ (utilisé comme opérateur).

Le fait que les commentaires multilignes soient un moyen relativement verbeux de le faire est une bonne chose, à mon avis, pour décourager les gens de l'utiliser avec désinvolture. Python a une continuation de ligne de barre oblique inverse, mais il est maintenant considéré comme une fonctionnalité de dernier recours . De même, dans la grande majorité de la syntaxe Julia, il existe déjà un moyen d'insérer un saut de ligne sans utiliser de syntaxe de continuation spéciale, et cela devrait être fortement préféré.

Salut @stevengj ,

Je ne sais pas pourquoi les gens devraient être découragés d'utiliser des sauts de ligne. Voir par exemple ce 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)

À mon humble avis, le signe d'opération à la fin n'est pas aussi bon que de les avoir au début:

            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)

C'est juste beaucoup plus naturel pour moi. Encore une fois, c'est un changement cosmétique, chacun aura un avis différent à ce sujet. La question est : cela nuira-t-il de quelque manière que ce soit à la conception du langage ?

Il semble plus facile de simplement mettre une paire de parenthèses supplémentaires dans ce cas.

Oui, ça peut se faire. Mais, encore une fois à mon humble avis, ce n'est pas courant. Disons que quelqu'un voit ça :

            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))

D'un point de vue mathématique, ces parenthèses n'ont aucun sens. Quelqu'un pourrait les supprimer par inadvertance, Julia n'affichera aucun avertissement et le code sera complètement faux.

La meilleure chose que j'ai pu trouver est \ comme dernier non-espace blanc sur une ligne, ce qui serait un changement radical car il s'agit actuellement d'une syntaxe valide mais étrange

Et si vous utilisiez # dans le même but ? L'interprétation est que vous commentez le saut de ligne. (merci @oxinabox d' avoir % comme continuation de commentaire/ligne)

Bon, de mon point de vue, un # en fin de ligne sans aucun caractère qui suit, devrait être très sympa et semble casser moins de choses.

Le seul problème potentiel que je vois ici est que passer de

a=1 #because reasons
 +2

à

a=1 #
 +2

produit des résultats différents. Cela n'a probablement pas d'importance cependant.

Qu'en est-il de quelque chose que Julia n'utilise pas comme \\ ? C'est trop moche ?

Je m'attendrais à ce que faire du style latex "Commenter le nouveau like" pour casser les choses.

À moins qu'il ne soit limité à seulement un # sans aucun espace après.
Par exemple:

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

Dans LaTeX, il n'y a pas de nouvelles lignes.
Et faire agir un commentaire vide différemment d'un commentaire non vide semble étrange.

Je ne le suggérais pas vraiment pour Julia.
Je pense que \\ serait beaucoup moins déroutant.
Mais je pense que la solution

Bien que faire des littéraux multilignes géants semble assez niche.
Encore plus que d'avoir des littéraux pour Array{T, 3} .

On devrait être capable de les construire tout aussi efficacement en utilisant les commandes vect et cat que le littéral abaisse de toute façon.

Je pense que la proposition était d'avoir un # suivi d'un caractère de nouvelle ligne uniquement (ou uniquement des espaces probablement).

Ouais, je voulais dire faire la suggestion de @StefanKarpinski de gestion spéciale de # à la fin d'une ligne, sans compter le cas où il y a d'autres trucs sans espace après le # . Peut-être que la comparaison LaTeX était plus déroutante que de clarification de ce que j'essayais de dire.

La cooptation de # me semble risquée. J'ai parfois des # éparpillés dans mon code, pour des raisons dont je ne me souviens pas très bien, des commentaires sur lesquels j'ai en quelque sorte changé d'avis, etc. Il serait très facile de supprimer par inadvertance un # s lors du 'nettoyage'.

Il me manque parfois un opérateur de continuation de ligne, mais je préférerais qu'il soit très explicite, comme \ ou ... . Les #= ou [] ressemblent un peu trop à un _truc_.

(Si l'utilisation doit être déconseillée, peut-être que quelque chose d'un peu moche, comme \\\ fonctionnerait ?)

Il est également tout à fait normal pour moi de mettre des commentaires après un opérateur de continuation de ligne, donc je n'aimerais pas avoir à compter sur le fait qu'il s'agit du dernier caractère non blanc de la ligne.

Je ne sais pas si elles sont déjà utilisées ailleurs ou si elles doivent être réservées à des opérateurs spécifiques à l'utilisateur, mais l'une de ces flèches Unicode peut constituer des options attrayantes et intuitives pour une continuation de ligne explicite :

↩ , ⬎ , ou ⤸

(rendu accessible, par exemple avec un alias significatif avec des tabulations, comme \continueline )

Je pense que c'est une chance que #= =# fonctionne pour ceci et nous devrions en rester là.

Je ne suis pas d'accord pour dire que mettre des barres obliques inverses à la fin de chaque ligne est en quelque sorte mieux que d'ajouter des parenthèses ou simplement de mettre les opérateurs à la fin de la ligne. Je ne pense pas non plus qu'abuser de la barre oblique inverse ou de # sera une amélioration ; cela ne ferait qu'ajouter des surprises. Si nous utilisions quelque chose à plusieurs caractères, ce ne serait alors pas une grande amélioration par rapport à #= =# .

Je ne suis pas d'accord pour dire que mettre des barres obliques inverses à la fin de chaque ligne est en quelque sorte mieux que d'ajouter des parenthèses ou simplement de mettre les opérateurs à la fin de la ligne.

La raison pour laquelle ce problème a été ouvert est qu'aucun de ceux-ci ne fonctionne pour les littéraux matriciels. Pourtant, je suis d'accord que nous ne devrions probablement rien faire pour cela puisque #= =# fonctionne déjà.

Maintenant que j'ai vu que vous pouvez utiliser #= =# pour la continuation de ligne, c'est parfaitement logique. Cependant, si je suis honnête, je ne serais certainement pas arrivé à cette conclusion par moi-même.

La meilleure façon d'avancer est peut-être d'ajouter quelque chose à la documentation et au guide de style Julia en disant que la continuation de ligne peut être réalisée via #= =# .

Juste pour terminer la discussion, @JeffBezanson et @StefanKarpinski , pensez-vous que même la suggestion proposée par @thchr , qui ne cassera rien, n'est pas bonne à mettre en œuvre ? Je pense que ce serait sympa quelque chose comme :

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

Moins verbeux que #= =# et visuellement agréable.

Cela se lit certes agréable. Un effet secondaire est que cela donnerait une manière canonique d'imprimer le code avec de longues lignes sur des écrans à largeur fixe de manière à ce que la sortie forme un code valide.

Cependant, nous analysons déjà de nombreuses flèches Unicode en tant qu'opérateurs binaires.

Je soupçonne que nous pourrions en épargner un.

Bonnes options à mon humble avis :

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

Il est peut-être temps de faire de l'espace blanc un opérateur, et nous pouvons le surcharger dans des contextes à grande matrice avec Cassette. Heureusement, Bjarne Stroustrup a déjà fait le gros travail de conception pour nous – http://www.stroustrup.com/whitespace98.pdf

Si nous utilisions quelque chose à plusieurs caractères, ce ne serait alors pas une grande amélioration par rapport à #= =# .

Je voudrais avancer trois arguments contre cela.

Premièrement, cela peut être confondu avec un commentaire. Même si je le sais, mon cerveau enregistre "Commentaire".

Deuxièmement, vous devez le mettre sur deux lignes, pas seulement sur une. (Comment cela va-t-il interagir avec l'indentation ?)

Troisièmement, c'est une combinaison de touches plus compliquée (sur mon ordinateur, c'est shift-3 shift-0 enter shift-0 shift-3 ). Je suppose qu'une sorte de raccourci clavier pourrait être utilisé. \\ est, en revanche, deux pressions rapides sur la même touche (suivies de enter .)

Trois et demi : à mon humble avis, cela a l'air un peu gênant et ressemble à un tour.

Même si le \\ n'est pas accepté car il peut être "réservé" pour une utilisation future, je pense vraiment que la suggestion de @thchr a l' air très sympa. Regardez comment ce sera :

            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)

Et, à part ça, personne ne sera obligé de l'utiliser et cela ne cassera rien. Mais je suis sûr qu'il y aura de bons cas d'utilisation pour cela (les grandes matrices qui m'ont amené à ouvrir ce numéro en sont une):

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 ⤸
     ...

à la place de

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 #=
     ...

Dans la mesure où un mur de nombres comme celui-ci peut jamais "être joli", il me semble beaucoup plus agréable de mettre chaque ligne sur une seule ligne. Au moins de cette façon, je peux dire combien de lignes la matrice a, et si les lignes ont la même longueur.

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 ...
       ...

Je pense que c'est génial qu'il existe un moyen évident d'écrire des expressions qui traversent plusieurs lignes, car la cohérence dans l'écosystème est plus importante que la flexibilité dans ce type de formatage.

Cela suggère que nous laissions les choses telles quelles, à une exception près : dans les contextes où les espaces blancs sont importants (macros, mais aussi construction matricielle), il n'y a actuellement aucun moyen évident de continuer les lignes. Le hack de commentaires sur plusieurs lignes est intelligent, mais aussi laid, IMO.

Nous pouvons résoudre les deux à la fois en ajoutant une continuation de ligne qui n'est valide que dans les contextes d'analyse space-sensitive :

# 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

J'ai implémenté l'unicode ⤸ pour la continuation de ligne dans la branche cjf/line-continuation . Il s'agit d'une version plus simple qui ne se limite pas aux contextes sensibles à l'espace, mais qui devrait être facile avec un peu de réarrangement.

Ce serait vraiment bien d'avoir une séparation de colonne combinée explicite continuation de ligne . Cela résoudrait le problème d'OP et améliorerait la lisibilité des expressions matricielles avec des formules. Exemple de simulation utilisant | ,

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

Pourquoi plus d'un caractère de continuation de ligne serait-il requis ?

Par souci d'avoir une proposition concrète, j'ai fait un PR pour cela - voir #29273

@c42f , à

Stefan : Seulement pour la lisibilité. Cela suggérerait seulement d'autoriser les caractères de continuation de ligne dans une ligne pour souligner et forcer la séparation des champs dans un contexte séparé par des espaces.

@ronisbr le fait qu'il n'y a qu'un seul moyen évident de continuer les lignes dans la plupart des expressions comme

x = a +
    b +
    c

m'attire plutôt et je ne voulais pas changer cela.

Permettre à ceci d'être également écrit comme

x =   a  ⤸
    + b  ⤸
    + c

introduit juste une variation inutile IMO.

Le langage a déjà le concept de contextes « sensibles à l'espace » où les règles d'analyse sont différentes, et cela s'intègre parfaitement là-dedans.

Salut les gars!

Maintenant que nous avons 1.1, pouvons-nous discuter de cette fonctionnalité pour 1.2 ? Au moins, pouvons-nous décider si cela deviendra éventuellement une nouvelle fonctionnalité ou si ce problème doit être fermé ?

cc @JeffBezanson , alias le tsar de la syntaxe.

Ayant trouvé des commentaires multilignes comme suggéré par @stevengj parfaitement adéquats à cet effet (et en général), je me demande si nous pourrions simplement le mentionner dans le manuel et ainsi résoudre le problème sans aucun changement de langue. Si oui, je serais heureux de faire un PR aux endroits pertinents (un pour les matrices, un comme conseil général).

Je me rends compte que certains langages ont une syntaxe spéciale pour cela, et c'est parfois utile. Cependant, je ne pense pas qu'écrire des lignes très longues ou inclure de grandes matrices littérales dans la source devrait devenir une habitude encouragée par la langue, plutôt que quelque chose pour laquelle nous avons juste un soutien dans les rares cas où cela est nécessaire.

Je suis d'accord que le cas de l'enveloppement de matrice multiligne est suffisamment inhabituel pour être couvert en utilisant #= =# et il vaudrait la peine de documenter cette option pour la continuation de ligne. Pour les invocations de macros multilignes, j'utilise cette syntaxe, mais je la trouve toujours moche et encombrante.

Pour les appels de macro multi-lignes, vous pouvez utiliser des parenthèses.

Je connais bien la possibilité d'utiliser des parenthèses pour les macros, mais je la trouve insatisfaisante comme je l'ai déjà décrit. À savoir, l'utilisation de parenthèses et de virgules rend l'invocation de macro très visuellement distincte de la façon dont les macros « regardent habituellement » dans la plupart des codes juila. Un code qui semble différent est plus difficile à lire.