Julia: Solicitação de recurso: adicionar operador para permitir linhas de quebra na definição da matriz

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

também funciona e não envolve a alocação de um array extra temporário [5] . Comentários multilinha (# 69) FTW!

(Embora, honestamente, eu não veja o problema de ter 150 flutuadores em uma linha. Os editores não têm barras de rolagem horizontais atualmente? Se você tiver uma matriz 150 × 150 em seu código, será apenas uma parede de 22.500 números de qualquer maneira, e a rolagem parece uma maneira tão boa quanto qualquer outra de ver isso em seu código. Você também pode ativar a quebra automática em seu editor, se gostar de linhas curtas.)

Não sei se os dois pontos .. são usados ​​em algum lugar, mas acho que é muito adequado para continuação de linha, ou \dots ( … ), -- , etc. Uma comparação de diferentes idiomas está aqui .

Olá @stevengj ,

Ainda estou acostumado a embrulhar meu código na coluna 80. IMHO, o código se torna muito mais legível e fácil de trabalhar porque você pode dividir seu editor em duas partes e ainda ver todo o código sem rolar.

Além disso, todas as línguas que me lembro têm algum mecanismo de continuação de linha. Isso realmente melhora a legibilidade do código em algumas ocasiões. Acho que Julia também deveria. Claro que você pode fazer tudo do jeito que está hoje, mas com esse recurso, acho que poderemos escrever um pouco mais claro.

O seu editor não pode fazer o empacotamento suave na coluna 80, se é isso que você prefere?

(Para a maior parte da linguagem Julia, você pode inserir quebras de linha sem hacks, por exemplo, após qualquer parêntese, vírgula ou operador binário. Matrizes literais são uma rara exceção.)

Dois pontos (..) e elipses (...) já são analisados ​​como operadores binários e, em geral, os operadores são muito mais úteis do que uma sintaxe de continuação que raramente surgiria (e já é possível com # = = #).

Oi @stevengj

Eu uso o vim (na verdade, o neovim), posso fazer soft wrapping, mas geralmente quebra coisas como vários cursores de linha e macros. É por isso que sempre prefiro quebrar as linhas.

No entanto, sinta-se à vontade para encerrar este problema se achar que esse recurso não funciona bem com o design da linguagem Julia.

Acho que o que realmente queremos é algo mais geral: uma maneira de continuar qualquer linha, não específica para a sintaxe da matriz. A melhor coisa que consegui pensar é \ como o último espaço não em branco em uma linha, o que seria uma alteração importante, já que atualmente é válida, mas uma sintaxe estranha:

x = y \
    z

Poderíamos até mesmo continuar a apoiar o uso de \ em contextos não sensíveis a espaços em branco, uma vez que y z é uma sintaxe inválida, mas isso provavelmente é um pouco inteligente. Não tenho certeza se vale a pena, mas a maioria dos idiomas tem uma maneira de continuar as linhas. O truque do comentário em várias linhas também funciona, mas é um pouco prolixo.

Muito quebrantado ...

julia> 2\
       10
5.0

julia> 2#=
       =#10
20

Definitivamente está quebrando, mas eu ficaria surpreso se \ fosse usado dessa forma com frequência.

Talvez #\ ? Claro, associar um novo comportamento a um comentário ignorado anteriormente também causa interrupções, mas ter #\ como comentário é provavelmente ainda menos comum do que quebrar uma linha após \ (usado como operador).

O fato de os comentários em várias linhas serem uma maneira relativamente prolixa de fazer isso é uma boa coisa, na minha opinião, para desencorajar as pessoas de usá-los casualmente. Python tem continuação de linha de barra invertida, mas agora é visto como um recurso de último recurso . Da mesma forma, na grande maioria da sintaxe Julia já existe uma maneira de inserir uma quebra de linha sem usar qualquer sintaxe de continuação especial, e isso deve ser fortemente preferido.

Olá @stevengj ,

Não sei por que as pessoas deveriam ser desencorajadas a usar quebras de linha. Veja por exemplo 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)

IMHO, o sinal de operação no final não é tão bom quanto tê-los no início:

            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)

Parece muito mais natural para mim. Novamente, é uma mudança cosmética, cada um terá uma opinião diferente sobre isso. A questão é: isso prejudicará em algum sentido o design da linguagem?

Parece mais fácil simplesmente colocar um par extra de parênteses nesse caso.

Sim, isso pode ser feito. Mas, novamente IMHO, não é comum. Digamos que alguém veja isto:

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

Do ponto de vista matemático, esses parênteses não têm significado. Alguém pode removê-los inadvertidamente, Julia não mostrará nenhum aviso e o código estará completamente errado.

A melhor coisa que consegui pensar é \ como o último espaço não em branco em uma linha, o que seria uma alteração importante, já que atualmente é uma sintaxe válida, mas estranha

Que tal usar # para o mesmo propósito? A interpretação é que você está comentando a quebra de linha. (obrigado @oxinabox por trazer esta interpretação do uso do LaTeX de % como comentário / continuação de linha)

Bem, do meu ponto de vista, um # no final da linha sem nenhum caractere seguindo, deve ser muito bom e parece quebrar menos coisas.

O único problema em potencial que vejo aqui é que ir de

a=1 #because reasons
 +2

para

a=1 #
 +2

produz resultados diferentes. Isso provavelmente não importa.

E algo que Julia não está usando, como \\ ? É muito feio?

Eu esperaria fazer estilo látex "Comentando o novo gosto" para quebrar as coisas.

A menos que fosse restrito a apenas # sem nenhum espaço não em branco depois.
Por exemplo:

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

Em LaTeX que não tem nenhuma linha nova.
E ter um comentário vazio agindo de forma diferente de um não vazio parece estranho.

Na verdade, eu não estava sugerindo isso para Julia.
Acho que \\ seria muito menos confuso.
Mas acho que a solução @stevengj para um comentário em

Embora fazer literais de várias linhas gigantes pareça um nicho muito bom.
Ainda mais do que ter literais por Array{T, 3} .

Deve-se ser capaz de construí-los com a mesma eficiência usando os comandos vect e cat que literalmente diminui para de qualquer maneira.

Acho que a proposta era ter um # seguido apenas por um caractere de nova linha (ou provavelmente apenas espaços).

Sim, eu quis dizer fazer a sugestão de @StefanKarpinski de tratamento especial de # no final de uma linha, definitivamente sem contar o caso onde há outras coisas que não sejam espaços em branco após # . Talvez a comparação do LaTeX tenha sido mais confusa do que esclarecedora para o que eu estava tentando dizer.

Cooptar # parece arriscado para mim. Às vezes tenho # s espalhados em meu código, por motivos que não me lembro, comentários sobre os quais mudei de ideia etc. Seria muito fácil remover inadvertidamente um # posterior

Ocasionalmente, perco um operador de continuação de linha, mas preferiria que fosse muito explicitamente óbvio, como \ ou ... . O #= ou [] parece um pouco demais com um _trick_.

(Se o uso for desencorajado, talvez algo um pouco feio, como \\\ funcione?)

Também é bastante normal para mim colocar comentários após um operador de continuação de linha, então eu não gostaria de ter que confiar que ele seja o último caractere diferente de espaço em branco na linha.

Não tenho certeza se eles já são usados ​​em outro lugar, ou devem ser reservados para operadores específicos do usuário, mas uma dessas setas Unicode pode fazer opções atraentes e intuitivas para continuação de linha explícita:

↩ , ⬎ , ou ⤸

(tornado acessível, por exemplo, com algum alias completo com tabulação, como \continueline )

Acho que é uma sorte que #= =# funcione para isso e devemos deixar por isso mesmo.

Não concordo que colocar barras invertidas no final de cada linha seja melhor do que adicionar parênteses ou apenas colocar os operadores no final da linha. Eu também não acho que abusar de barra invertida ou # será uma melhoria; isso apenas acrescentaria surpresas. Se usássemos algo com vários caracteres, não seria uma grande melhoria em relação a #= =# .

Não concordo que colocar barras invertidas no final de cada linha seja melhor do que adicionar parênteses ou apenas colocar os operadores no final da linha.

A razão pela qual este problema foi aberto foi que nenhum desses funcionam para literais de matriz. Ainda assim, concordo que provavelmente não devemos fazer nada para isso, pois #= =# já funciona.

Agora que vi que você pode usar #= =# para continuação de linha, faz todo o sentido. No entanto, se estou sendo honesto, definitivamente não teria chegado a essa conclusão sozinho.

Talvez a melhor maneira de avançar seja adicionar algo à documentação e ao guia de estilo Julia dizendo que a continuação da linha pode ser alcançada por meio de #= =# .

Só para encerrar a discussão, @JeffBezanson e @StefanKarpinski , vocês acham que mesmo a sugestão proposta por @thchr , que não vai quebrar nada, não é boa para ser implementada? Acho que vai ser bom algo como:

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

Menos prolixo do que #= =# e visualmente agradável.

Isso parece reconhecidamente bom. Um efeito colateral é que isso daria uma maneira canônica de imprimir código com linhas longas em telas de largura fixa de forma que a saída formas um código válido.

Já analisamos muitas setas Unicode como operadores binários, no entanto.

Suspeito que poderíamos ceder um.

Boas opções IMHO:

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

Talvez seja hora de transformar o espaço em branco em um operador, e podemos sobrecarregá-lo em contextos de matriz grande com Cassete. Felizmente, Bjarne Stroustrup já fez o trabalho de design pesado para nós - http://www.stroustrup.com/whitespace98.pdf

Se usássemos algo com vários caracteres, não seria uma grande melhoria em relação a #= =# .

Gostaria de apresentar três argumentos contra isso.

Em primeiro lugar, isso pode ser confundido com um comentário. Mesmo que eu saiba disso, meu cérebro registra "Comentário".

Em segundo lugar, você deve colocá-lo em duas linhas, não apenas em uma. (Como isso vai interagir com o recuo?)

Em terceiro lugar, é uma combinação mais complicada de pressionamentos de tecla (no meu computador é shift-3 shift-0 enter shift-0 shift-3 ). Acho que algum tipo de atalho de teclado pode ser usado. \\ são, em contraste, dois toques rápidos da mesma tecla (seguidos por enter .)

Três anos e meio: IMHO, parece um pouco estranho e parece um truque.

Mesmo que \\ não seja aceito porque pode estar "reservado" para uso futuro, eu realmente acho que a sugestão de @thchr parece muito boa. Olha como vai ser:

            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)

E, além disso, ninguém será obrigado a usar isso e não vai quebrar nada. Mas tenho certeza de que haverá bons casos de uso para isso (a grande matriz que me levou a abrir este problema é uma):

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

ao invés 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 #=
     ...

Na medida em que uma parede de números como essa sempre pode "parecer bonita", parece muito mais agradável para mim colocar cada linha em uma única linha. Pelo menos assim posso dizer quantas linhas a matriz tem e se as linhas têm o mesmo comprimento.

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

Acho ótimo que haja uma maneira óbvia de escrever expressões que cruzam várias linhas, porque a consistência em todo o ecossistema é mais importante do que a flexibilidade neste tipo de formatação.

Isto sugere que deixar as coisas como é, exceto por uma coisa: em contextos onde o espaço em branco é significativa (macros, mas também de construção de matriz) há atualmente zero maneiras óbvias para continuar linhas. O hack de comentários de várias linhas é inteligente, mas também feio, IMO.

Podemos resolver ambos de uma vez adicionando uma continuação de linha que só é válida em contextos de análise 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

Implementei unicode ⤸ para continuação de linha no ramo cjf/line-continuation . Esta é uma versão mais simples, não restrita a contextos sensíveis ao espaço, mas que deve ser fácil com um pouco de reorganização.

Seria muito bom ter uma separação de coluna combinada explícita continuação de linha . Isso resolveria o problema de OP e aumentaria a legibilidade das expressões de matriz com fórmulas. Exemplo simulado usando | ,

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

Por que mais de um caractere de continuação de linha seria necessário?

Para ter uma proposta concreta, fiz um PR para isso - consulte # 29273

@ c42f , IMHO, acho que será um pouco confuso permitir o caractere de continuação de linha apenas em ocasiões específicas. Por que não podemos permitir que seja global?

Stefan: Apenas para facilitar a leitura. Isso sugeriria apenas permitir caracteres de continuação de linha dentro de uma linha para enfatizar e forçar a separação de campo em contexto separado por espaços em branco.

@ronisbr o fato de que há apenas uma maneira óbvia de continuar as linhas na maioria das expressões como

x = a +
    b +
    c

é bastante atraente para mim e eu não queria mudar isso.

Permitindo que isso também seja escrito como

x =   a  ⤸
    + b  ⤸
    + c

apenas introduz variação desnecessária IMO.

A linguagem já tem o conceito de contextos "sensíveis ao espaço" onde as regras de análise são diferentes, e isso se encaixa perfeitamente neles.

Oi, pessoal!

Agora que temos 1.1, podemos discutir esse recurso para 1.2? Pelo menos, podemos decidir se isso acabará por se tornar um novo recurso ou se este problema deve ser resolvido?

cc @JeffBezanson , também conhecido como czar da sintaxe.

Tendo encontrado comentários em várias linhas sugeridos por @stevengj perfeitamente adequados para este propósito (e em geral), eu me pergunto se poderíamos apenas mencionar isso no manual e assim resolver o problema sem qualquer alteração no idioma. Se sim, terei todo o gosto em fazer uma RP nos locais relevantes (uma para matrizes, outra para aconselhamento geral).

Eu percebo que algumas linguagens têm sintaxe especial para isso, e que ocasionalmente é útil. No entanto, não acho que escrever linhas superlongas ou incluir grandes matrizes literais na fonte deva se tornar um hábito encorajado pela linguagem, ao invés de algo para o qual apenas temos algum suporte no raro caso de ser necessário.

Eu concordo que o caso do empacotamento de matriz multilinha é suficientemente incomum para ser coberto pelo uso de #= =# e valeria a pena documentar essa opção para a continuação de linha. Para invocações de macro multilinhas, eu uso essa sintaxe, mas ainda a considero feia e complicada.

Para chamadas de macro multilinhas, você pode usar parênteses.

Estou bem ciente da opção de usar parênteses para macros, mas não o considero satisfatório, conforme descrevi antes. Ou seja, o uso de parênteses e vírgulas torna a invocação da macro muito visualmente distinta da forma como as macros "normalmente se parecem" na maioria dos códigos juila. O código que parece diferente é mais difícil de ler.