Julia: Solicitud de función: agregar operador para permitir líneas de ruptura en la definición de matriz

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

también funciona y no implica la asignación de un arreglo temporal adicional [5] . Comentarios multilínea (# 69) ¡FTW!

(Aunque, honestamente, no veo el problema de tener 150 flotantes en una línea. ¿No tienen los editores barras de desplazamiento horizontales en estos días? Si tiene una matriz de 150 × 150 en su código, solo será una pared de 22500 números. de todos modos, y el desplazamiento parece una forma tan buena como cualquier otra de verlo en su código. También puede activar el ajuste suave en su editor si le gustan las líneas cortas).

No sé si los dos puntos .. se usan en algún lugar, pero creo que es muy adecuado para la continuación de línea, o \dots ( … ), -- , etc. Aquí encontrará una

Hola @stevengj ,

Todavía estoy acostumbrado a ajustar mi código en la columna 80. En mi humilde opinión, el código se vuelve mucho más legible y más fácil de trabajar porque puede dividir su editor en dos partes y aún ver todo el código sin desplazarse.

Además de eso, todos los idiomas que recuerdo tienen algún mecanismo para la continuación de línea. Esto realmente mejora la legibilidad del código en algunas ocasiones. Creo que Julia también debería haberlo hecho. Por supuesto que puedes hacer todo como está hoy, pero con esa característica, creo que podremos escribir un poco más claro.

¿No puede su editor hacer un ajuste suave en la columna 80 si eso es lo que prefiere?

(Para la mayor parte del lenguaje Julia, puede insertar saltos de línea sin cortes, por ejemplo, después de cualquier par, coma o operador binario. Las matrices literales son una rara excepción).

Dos puntos (..) y elipses (…) ya están analizados como operadores binarios y, en general, los operadores son mucho más útiles que una sintaxis de continuación que solo surgiría raramente (y ya es posible con # = = #).

Hola @stevengj

Yo uso vim (en realidad neovim), puedo hacer un ajuste suave pero generalmente rompe cosas como cursores de línea múltiple y macros. Por eso siempre prefiero romper líneas.

Sin embargo, no dude en cerrar este problema si cree que dicha función no funciona bien con el diseño del lenguaje de Julia.

Creo que lo que realmente queremos es algo más general: una forma de continuar cualquier línea, no específica de la sintaxis de la matriz. Lo mejor que se me ha ocurrido es \ como el último espacio no en blanco en una línea, lo que sería un cambio rotundo ya que actualmente es una sintaxis válida pero extraña:

x = y \
    z

Incluso podríamos seguir apoyando el uso de \ en contextos no sensibles a los espacios en blanco, ya que y z es una sintaxis inválida, pero probablemente sea demasiado inteligente. No estoy seguro de que valga la pena, pero la mayoría de los idiomas tienen una forma de continuar las líneas. El truco de comentarios de varias líneas también funciona, pero es un poco detallado.

Muy rompiendo ...

julia> 2\
       10
5.0

julia> 2#=
       =#10
20

Definitivamente se está rompiendo, pero me sorprendería si \ se usara así a menudo.

¿Quizás #\ ? Claro, asociar un nuevo comportamiento a un comentario previamente ignorado también se rompe, pero tener #\ como comentario es probablemente incluso menos común que romper una línea después de \ (usado como operador).

El hecho de que los comentarios de varias líneas sean una forma relativamente detallada de hacer esto es algo bueno, en mi opinión, para disuadir a las personas de usarlos de manera casual. Python tiene una continuación de línea de barra invertida, pero ahora se ve como una característica de último recurso . De manera similar, en la gran mayoría de la sintaxis de Julia ya existe una forma de insertar un salto de línea sin usar ninguna sintaxis de continuación especial, y eso debería ser muy preferido.

Hola @stevengj ,

No estoy seguro de por qué debería desanimarse a la gente a utilizar saltos de línea. Vea, por ejemplo, este código:

            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)

En mi humilde opinión, el signo de operación al final no es tan bueno como tenerlos al principio:

            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)

Se siente mucho más natural para mí. Nuevamente, es un cambio cosmético, cada uno tendrá una opinión diferente al respecto. La pregunta es: ¿dañará en algún sentido el diseño del lenguaje?

Parece más fácil simplemente poner un par adicional de paréntesis en ese caso.

Sí, se puede hacer. Pero, nuevamente en mi humilde opinión, no es común. Digamos que alguien ve esto:

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

Desde un punto de vista matemático, esos paréntesis no tienen significado. Alguien podría eliminarlos inadvertidamente, Julia no mostrará ninguna advertencia y el código será completamente incorrecto.

Lo mejor que se me ha ocurrido es \ como el último espacio no en blanco en una línea, lo que sería un cambio rotundo ya que actualmente es una sintaxis válida pero extraña

¿Qué hay de usar # para el mismo propósito? La interpretación es que estás comentando el salto de línea. (gracias @oxinabox por traer a colación esta interpretación del uso de LaTeX de % como comentario / continuación de línea)

Bueno, desde mi punto de vista, un # al final de la línea sin ningún carácter a continuación, debería ser muy agradable y parece romper menos cosas.

El único problema potencial que veo aquí es que pasar de

a=1 #because reasons
 +2

para

a=1 #
 +2

produce resultados diferentes. Sin embargo, esto probablemente no importe.

¿Qué pasa con algo que Julia no está usando como \\ ? ¿Es demasiado feo?

Esperaría hacer un estilo de látex "Comentar el nuevo me gusta" para romper las cosas.

A menos que esté restringido a solo # sin ningún espacio en blanco después.
Por ejemplo:

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

En LaTeX que no tiene nuevas líneas.
Y tener un comentario vacío que actúe de manera diferente a uno no vacío suena extraño.

En realidad, no se lo estaba sugiriendo a Julia.
Creo que \\ sería mucho menos confuso.
Pero creo que la solución de @stevengj de un comentario de

Aunque hacer literales multilínea gigantes parece bastante nicho.
Incluso más que tener literales por Array{T, 3} .

Uno debería poder construirlos con la misma eficiencia usando los comandos vect y cat que literalmente se reduce a de todos modos.

Creo que la propuesta era tener un # seguido de un carácter de nueva línea solo (o solo espacios probablemente).

Sí, me refiero a hacer la sugerencia de @StefanKarpinski de un manejo especial de # al final de una línea, definitivamente sin contar el caso donde hay otras cosas que no son espacios en blanco después de # . Quizás la comparación de LaTeX fue más confusa que aclarar lo que estaba tratando de decir.

Cooptar # parece arriesgado. A veces tengo # s dispersos en mi código, por razones que no recuerdo del todo, comentarios sobre los que cambié de opinión, etc. Sería muy fácil eliminar inadvertidamente un # final

Ocasionalmente pierdo un operador de continuación de línea, pero preferiría que fuera muy explícitamente obvio, como \ o ... . Los #= o [] parecen demasiado como un _ truco_.

(Si se desea desalentar el uso, ¿tal vez algo un poco feo, como \\\ funcionaría?)

También es bastante normal para mí poner comentarios después de un operador de continuación de línea, por lo que no me gustaría tener que depender de que sea el último carácter que no sea un espacio en blanco en la línea.

No estoy seguro de si ya se usan en otro lugar o si deberían reservarse para operadores específicos del usuario, pero una de estas flechas Unicode puede ser opciones atractivas e intuitivas para la continuación de línea explícita:

↩ , ⬎ o ⤸

(se hace accesible, por ejemplo, con un alias significativo completado con tabulación, como \continueline )

Creo que es una suerte que #= =# funcione para esto y deberíamos dejarlo así.

No estoy de acuerdo en que poner barras invertidas al final de cada línea sea de alguna manera mejor que agregar paréntesis o simplemente poner los operadores al final de la línea. Tampoco creo que abusar de la barra invertida o # sea ​​una mejora; eso solo agregaría sorpresas. Si usáramos algo de varios caracteres, no sería una gran mejora con respecto a #= =# .

No estoy de acuerdo en que poner barras invertidas al final de cada línea sea de alguna manera mejor que agregar paréntesis o simplemente poner los operadores al final de la línea.

La razón por la que se abrió este problema fue que ninguno de esos funciona para literales de matriz. Aún así, estoy de acuerdo en que probablemente no deberíamos hacer nada al respecto ya que #= =# ya funciona.

Ahora que he visto que puedes usar #= =# para la continuación de la línea, tiene mucho sentido. Sin embargo, si soy honesto, definitivamente no habría llegado a esa conclusión por mí mismo.

Quizás la mejor manera de avanzar es agregar algo a la documentación y la guía de estilo de Julia que diga que la continuación de la línea se puede lograr a través de #= =# .

Solo para terminar la discusión, @JeffBezanson y @StefanKarpinski , ¿creen que incluso la sugerencia propuesta por @thchr , que no romperá nada, no es buena para ser implementada? Creo que será bueno algo como:

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

Menos detallado que #= =# y visualmente agradable.

Esto se lee ciertamente bien. Un efecto secundario es que esto daría una forma canónica de imprimir código con líneas largas en pantallas de ancho fijo de manera que la salida forme un código válido.

Sin embargo, ya analizamos muchas flechas Unicode como operadores binarios.

Sospecho que podríamos prescindir de uno.

Buenas opciones en mi humilde opinión:

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

Quizás es hora de convertir el espacio en blanco en un operador, y podemos sobrecargarlo en contextos de matriz grande con Cassette. Afortunadamente, Bjarne Stroustrup ya hizo el arduo trabajo de diseño por nosotros: http://www.stroustrup.com/whitespace98.pdf

Si usáramos algo de varios caracteres, no sería una gran mejora con respecto a #= =# .

Me gustaría presentar tres argumentos en contra de esto.

En primer lugar, esto puede confundirse con un comentario. Incluso si sé esto, mi cerebro registra "Comentario".

En segundo lugar, debes ponerlo en dos líneas, no solo en una. (¿Cómo interactuará esto con la sangría?)

En tercer lugar, es una combinación más complicada de pulsaciones de teclas (en mi computadora es shift-3 shift-0 enter shift-0 shift-3 ). Supongo que se podría usar algún tipo de atajo de teclado. \\ son, por el contrario, dos pulsaciones rápidas de la misma tecla (seguidas de enter .)

Tres y medio: en mi humilde opinión, se ve un poco incómodo y se siente como un truco.

Incluso si el \\ no se acepta porque tal vez esté "reservado" para uso futuro, realmente creo que la sugerencia de @thchr se ve muy bien. Mira como quedará:

            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)

Y, además de eso, nadie se verá obligado a usar esto y no romperá nada. Pero estoy seguro de que habrá buenos casos de uso para esto (las grandes matrices que me llevaron a abrir este problema es una):

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

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

En la medida en que una pared de números como esa pueda "verse bien", me parece mucho más agradable poner cada fila en una sola línea. Al menos de esa manera puedo decir cuántas filas tiene la matriz y si las filas tienen la misma longitud.

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

Creo que es genial que haya una forma obvia de escribir expresiones que crucen varias líneas porque la coherencia en todo el ecosistema es más importante que la flexibilidad en este tipo de formato.

Esto sugiere que dejar las cosas como es, excepto por una cosa: en contextos en los espacios en blanco es significativo (macros, sino también la construcción de la matriz) no hay actualmente cero maneras obvias para seguir las líneas. El truco de comentarios de varias líneas es inteligente, pero también feo, en mi opinión.

Podemos resolver ambos a la vez agregando una continuación de línea que solo es válida en contextos de análisis 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

Implementé unicode ⤸ para la continuación de línea en la rama cjf/line-continuation . Esta es una versión más simple no restringida a contextos sensibles al espacio, pero debería ser fácil con un poco de reordenamiento.

Sería realmente bueno tener una separación de columna combinada explícita continuación de fila . Resolvería el problema de OP y mejoraría la legibilidad de las expresiones matriciales con fórmulas. Ejemplo simulado usando | ,

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

¿Por qué se requeriría más de un carácter de continuación de línea?

En aras de tener una propuesta concreta, hice un PR para esto - vea # 29273

@ c42f , en mi humilde opinión, creo que será algo confuso permitir el carácter de continuación de línea solo en ocasiones específicas. ¿Por qué no podemos dejar que sea global?

Stefan: Solo para facilitar la lectura. Esto solo sugeriría permitir caracteres de continuación de línea dentro de una línea para enfatizar y forzar la separación del campo en un contexto separado por espacios en blanco.

@ronisbr el hecho de que solo hay una forma obvia de continuar líneas en la mayoría de expresiones como

x = a +
    b +
    c

es bastante atractivo para mí y no quería cambiar eso.

Permitiendo que esto también se escriba como

x =   a  ⤸
    + b  ⤸
    + c

simplemente introduce una variación innecesaria en mi opinión.

El lenguaje ya tiene el concepto de contextos "sensibles al espacio" donde las reglas de análisis son diferentes, y esto encaja perfectamente allí.

¡Hola tios!

Ahora que tenemos 1.1, ¿podemos discutir esta característica para 1.2? Al menos, ¿podemos decidir si esto eventualmente se convertirá en una nueva característica o si este problema debería cerrarse?

cc @JeffBezanson , también conocido como el zar de la sintaxis.

Habiendo encontrado los comentarios multilínea sugeridos por @stevengj perfectamente adecuados para este propósito (y en general), me pregunto si podríamos mencionar esto en el manual y así resolver el problema sin ningún cambio en el idioma. Si es así, estaría encantado de hacer un RP en los lugares relevantes (uno para matrices, otro como consejo general).

Me doy cuenta de que algunos lenguajes tienen una sintaxis especial para esto, y que ocasionalmente es útil. Sin embargo, no creo que escribir líneas superlargas o incluir grandes matrices literales en la fuente deba convertirse en un hábito fomentado por el lenguaje, en lugar de algo para lo que solo tengamos algún soporte en el raro caso de que sea necesario.

Estoy de acuerdo en que el caso de la envoltura de matriz multilínea es lo suficientemente inusual como para cubrirlo usando #= =# y valdría la pena documentar esta opción para la continuación de la línea. Para las invocaciones de macros de varias líneas, utilizo esta sintaxis, pero todavía la encuentro fea y engorrosa.

Para llamadas de macro de varias líneas, puede utilizar paréntesis.

Soy muy consciente de la opción de usar parens para macros, pero me resulta insatisfactorio como he descrito antes. Es decir, el uso de paréntesis y comas hace que la invocación de macros sea muy distinta visualmente de la forma en que las macros "suelen verse" en la mayoría del código juila. El código que se ve diferente es más difícil de leer.