O único problema que isso não resolve é o aninhamento, mas aqui está uma ideia que também trata disso. E se o aninhamento for baseado no recuo e no número de # caracteres? Como em, eles precisam se combinar para serem emparelhados. Então você pode fazer coisas assim:

###
function foo(x,y)
  ###
    There seems to be an odd bug in the following
    very complex code that I have yet to discover
  ###
  while x < y
    # ...
  end
end
###

Aqui, você pode aninhar facilmente o comentário de várias linhas interno dentro da função porque é recuado, enquanto o comentário de várias linhas externa que oculta totalmente a definição da função é alinhado à esquerda.

#####
bar(x,y) = foo(x+y,y)

###
  Another multi-line comment
  that has no real content
###
baz(x,y) = foo(x,x+y)
#####

Nesse caso, você tem um comentário de várias linhas aninhado dentro de outro usando um número diferente de marcas de hash, permitindo que você comente facilmente blocos de código que já têm comentários de várias linhas, apenas usando mais marcas de hash.

Estou imaginando que você usaria principalmente ### para comentários normais de várias linhas em linha e #### e assim por diante para comentar blocos de código, mas é claro, essa é uma convenção que cabe às pessoas codificar. Isso apenas facilita.

Observe que, ao contrário dos comentários de multilinhas no estilo /* ... */ , você não precisa controlar os pares balanceados para lidar com o aninhamento corretamente: tudo o que você precisa fazer para encontrar o par de fechamento correto é o recuo e o número de # . Muito mais simples.

Não sei, acho que é mais difícil de usar porque para comentar uma região você tem que olhar para encontrar o maior número de #s e adicionar 1. Meu palpite é que um par de símbolos simétricos é o mais fácil.

Por que não podemos usar /* ... */ para comentários aninhados ou ### ... ### ? Isso não poderia ser tratado como blocos aninhados, assim como no resto do analisador? Não podemos simplesmente tratar os comentários /* ou ### como operadores e os comentários como códigos? Isso pode permitir outras coisas legais mais tarde também.

Sou inflexivelmente contra /* ... */ comentários, e ainda sou a favor dos ### comentários. Eu entendo o ponto de Jeff, mas não acho que seja grande coisa. Honestamente, essa é realmente uma preocupação do editor, e bastante branda. Portanto, seu editor tem que trabalhar um pouco mais, potencialmente. Tanto faz. Para os humanos, acho que esse esquema é muito útil e estético. Isso ou nenhum comentário de várias linhas, o que, com um suporte decente do editor, não é grande coisa.

Não acho que precisamos de recursos sofisticados em torno dos comentários. Os comentários são especialmente fáceis de analisar, por isso não é muito difícil escrever ferramentas externas para extrair a documentação.
Eu meio que gosto de #| ... |# como um aceno de cabeça, mas não espero que mais ninguém aprecie isso. Eu concordo que ### parece bom. Mas por enquanto não vamos fazer nada e dormir um pouco mais sobre isso.

Acordado. Você sempre pode adicionar novos estilos de comentários (embora ### comentários não sejam estritamente compatíveis com as versões anteriores), mas alterar os estilos de comentários é muito mais problemático. Definitivamente, um recurso v2.0 (se houver).

Os editores são bons hoje em dia. Comentários multilinha não são realmente necessários.

Eu sou novo para Julia, fui informado disso através do Slashdot. Parece-me que encerrar esta edição vai contra o seu manifesto " Por que criamos

Certamente nunca dissemos que “queremos criar uma linguagem que agrade a todos”; isso é claramente impossível.

Deixe-me reafirmar, então: você deseja combinar as melhores características de seus idiomas favoritos. A velocidade do C, o dinamismo do Ruby, etc ... e a falta de comentários multilinhas do Python? Acho que simplesmente não vejo uma razão convincente para excluí-los (se for uma falta de tempo / interesse do desenvolvedor, a solicitação de recurso não deveria ser deixada em aberto?).

Não sou totalmente contra isso. Acho que, na maioria das vezes, não encontramos uma sintaxe de que realmente gostamos.
Se escolhermos uma sintaxe para isso, ela deve se aninhar facilmente, já que parece ser o único recurso que as pessoas gostam nos comentários de várias linhas.
Alguma sugestão, @benkehoe ?

A postagem do blog requer um pouco de licença artística ... não é para ser um artigo científico. Não somos literalmente tão dinâmicos quanto ruby ​​(ou, é claro, tão rápidos quanto C em geral, ainda) e também não estamos apenas combinando recursos de outras linguagens.

Eu não tive a intenção de atribuir intenções exatas a você em nenhum dos meus comentários, apenas a ideia geral de que uma boa linguagem burra de carga deve ter comentários de várias linhas (e comentários de uma única linha, como C eventualmente levou a sério após 20 anos). Parece-me que se o aninhamento for desejado, a sintaxe deve ser algo _como_ /* ... */ , ou seja, com marcadores de início e fim distintos. # deve estar envolvido, pois é o "caractere de comentário". #| ... |# não é terrível, embora talvez os colchetes de algum tipo sejam melhores, seja no interior como #( ... )# ou no estilo MATLAB #( ... #) , embora eu ache que você possa ter problemas para comentar argumentos ou indexação.

Que tal agora:

#begin
  This is a comment.
#end

Eu ainda gosto muito do esquema de comentário multilinha derivado do CoffeeScript original. Se um exigir recuo e número de # chars para corresponder, ele é muito aninhado sem exigir análise real.

#begin/#end parece muita digitação. Acho que ### é bom, exceto pelo bit de aninhamento: nada do resto da linguagem reconhece espaços em branco, certo? Não me importo com comentários em bloco que não possam ser aninhados , mas como # provavelmente seria fácil de usar se você deixasse de fora a parte do recuo. O que há de errado com #| ... |# ?

Cada combinação de #x x# parece estranha para mim. Experimente em várias linhas:

#|
  comment here
|#

nenhum comentário com várias linhas é adequado, se muito, muito desejado, / * * / está ok

De todas as possibilidades, eu gosto ### da melhor.

@ViralBShah , você quer dizer não aninhado? A outra coisa com o aninhamento de recuo é que ele quebra a capacidade de um editor de fazer recuo automático de código. @StefanKarpinski , por que você precisaria de indentação _e_ número de caracteres para facilitar a análise? O número de caracteres não seria suficiente?

### parece bom. Mas se pode haver qualquer número de #s, evita formas comuns de arte ASCII de comentário :)
Talvez aninhar não seja tão importante. Poderíamos começar com ### e adicionar a versão de aninhamento, se parecer necessário. Ou podemos usar ###{ }### para aninhamento; talvez se alguém realmente se preocupa com o ninho, não se importe com a feiura.

Isso parece bastante razoável.

(para seu prazer)

Se você escolher usar pares de caracteres de tabulação para comentários de várias linhas, use pares de tabulação para comentários de várias linhas aninhados.
Essa parcimônia de decisão oferece harmonia ao usuário. Você não deve se preocupar com o quão relativamente recuado é o par aninhado.

usando pares de octothorpe agudos

###
   one, two, three
   three twenty one
###

###
      # one, two, three 
      three twenty one
   ###
     one, two, three 
     three twenty one
   ###
###

usando pares octothorpe vertical_bar

#|
   one, two, three
   three twenty one
|#

#|
      # one, two, three 
      three twenty one
   #|
     one, two, three 
     three twenty one
   |#
|#

usando pares de exclamação octothorpe

#!
   one, two, three
   three twenty one
!#

#!
      # one, two, three 
      three twenty one
   #!:
     one, two, three 
     three twenty one
   !#
!#

usando pares de octothorpe cólon

#:
   one, two, three
   three twenty one
:#

#:
      # one, two, three 
      three twenty one
   #:
     one, two, three 
     three twenty one
   :#
:#

Eu pessoalmente gosto mais da opção ### recuada. Parece intuitivo, fácil de digitar e simétrico. #begin / #end são boas opções, pois estariam perfeitamente alinhadas com o resto da sintaxe da linguagem e permitiriam o aninhamento sem torná-lo dependente de espaços em branco.

Eu não gosto de #( ... )# e opções semelhantes, uma vez que essas quebram a simetria (como Stefan disse, qualquer construção #x ... x# parece muito melhor inline do que realmente se estender por várias linhas) e tornam mais difícil alternar os comentários de várias linhas ( as opções acima simplesmente exigiriam a inserção / remoção de um espaço após o primeiro caractere # para convertê-los em comentários regulares de uma linha).

Para sua informação, o plugin do editor kate agora pode "dobrar" comentários entre colchetes #BEGIN ... # END (uma sugestão do pessoal do KDE). Essa escolha pode mudar, é claro, e eu gosto das letras minúsculas. Pretendia anunciar / pedir opiniões, mas estou muito ocupado, então acho que esta é a oportunidade.

Eu prefiro #bgn .. #end (acho que comprimentos de tag correspondentes tornam a varredura visual mais agradável).

Não obstante, eu prefiro muito mais copiar da forma como Julia demarca comentários de várias linhas :-)

Embora seja legal, outros blocos não combinam com o comprimento end . for , let e try acontecer a fazê-lo, mas while , function , etc não, então abreviar a #bgn quebraria o padrão atual.

verdade o suficiente

Eu ficaria feliz em receber vários comentários como parte da Julia com qualquer
emparelhamento.

_begin ... end_ não introduz um novo escopo - presumivelmente _ # begin .. * _

end * também não. Se acontecer de ser o caso de tratar multilinhas

comentários como um escopo distinto são úteis, então eu prefiro _ # cmt_ * ... # *
_end_ ou (se manter o conjunto de tokens atual for importante) _ # let ... #end_.

Na quinta-feira, 1º de novembro de 2012 às 18:28, Waldir [email protected] escreveu:

Embora seja legal, outros blocos não combinam comprimento com extremidade. para, letand
tente fazer isso, mas while, function, etc não, então abreviando para

bgn quebraria o padrão atual.

-
Responda diretamente a este e-mail ou visualize-o em Gi tHubhttps: //github.com/JuliaLang/julia/issues/69#issuecomment -9998478.

Recentemente, eu estava olhando para comentários de várias linhas para uma DSL. Um problema que encontrei foi que, ao fazer a varredura por meio de código não realçado pela sintaxe, ajudou a ter diferentes strings de abertura e fechamento. No final, usei o seguinte:

msg = "Hello."
----
Nesting is done using additional characters
---
I really don't have a complex code example to 
write but somehow I have lots of things to say about it.
===
====
println(msg)

Alguns pensamentos:

Um problema que pode surgir com ### é quando você tem 3 camadas de comentários de uma única linha, que eu classificaria como não frequentes, mas ainda acontecendo às vezes:

# foo()
## for i = 1:3
###     baz() # Hu-ho, where is the closing symbol?
##     buzz()
## end

Paradoxalmente, os comentários de várias linhas geralmente são úteis em uma única linha, como esta:

f(x, /* y, */ z) // I want to try f without this argument... quick and dirty
f(/* unused */ x, y) // inlined comment

Você também pode fazer isso com um comentário de uma única linha:

f(x,
#  y,
  z)
f(x, # unused
  y)

mas a primeira abordagem às vezes pode ser útil.

Acho que o par #(# - #)# ficaria bem legal. Demo:

f(x, #(# y, #)# z)

foo()
#(#
for i = 1:3
  #(#
     baz()
     baz2()
  #)#
     buzz()
end
#)#

Benefícios:

• o caractere # faz com que pareça um comentário
• os parênteses tornam os símbolos de abertura e fechamento óbvios e concisos
• o último caractere # faz com que pareça melhor (quase simétrico), especialmente quando escrito em sua própria linha
• uma vez que os símbolos de abertura e fechamento são diferentes, eles devem ser fáceis de analisar e o aninhamento pode ser permitido

A preferência inicial de Jeff está bem para mim.
# | ... | #

Se a escolha entre um emparelhamento de 3 caracteres e um emparelhamento de 2 caracteres, eu
prefira o menos intrusivo visualmente.

Na sexta-feira, 30 de novembro de 2012 às 19h32, Simon Leblanc [email protected] :

Alguns pensamentos:

Um problema que pode surgir com ### é quando você tem 3 camadas de
comentários de linha, que eu classificaria como não frequentes, mas ainda acontecendo
as vezes:

foo ()

para i = 1: 3

baz () # Hu-ho, onde está o símbolo de fechamento?

zumbido()

fim

---

Paradoxalmente, os comentários de várias linhas são frequentemente úteis em uma única linha, como
esta:

f (x, / * y, _ / z) // Eu quero tentar f sem este argumento ... rápido e sujo
f (/ _ não utilizado * / x, y) // comentário embutido

Você também pode fazer isso com um comentário de uma única linha:

f (x,

y,

z)
f (x, # não utilizado
y)

mas a primeira abordagem às vezes pode ser útil.

Acho que o par # (# - #) # ficaria bem legal. Demo:

f (x, # (# y, #) # z)

foo ()

(

para i = 1: 3
# (#
baz ()
baz2 ()
#) #
zumbido()
fim

)

Benefícios:

• o caractere # faz com que pareça um comentário
• os parênteses tornam os símbolos de abertura e fechamento óbvios e concisos
• o último # caractere faz com que pareça melhor (quase simétrico)
  especialmente quando escrito em sua própria linha
• uma vez que os símbolos de abertura e fechamento são diferentes, eles devem ser fáceis
  para analisar e aninhar pode ser permitido

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/JuliaLang/julia/issues/69#issuecomment -10909823.

Direi que se eu fosse adicionar isso, a única coisa que consideraria algo como # | | # ou # () #, já que eles se aninham e não entram em conflito com a arte ASCII feita de #, que deve ser suportada :)

Esta é a maior bicicleta de todos os tempos.

Dos dois, # () # é mais fácil de digitar (menos movimento da mão).

Na sexta-feira, 30 de novembro de 2012 às 20h26, Jeff Bezanson [email protected] :

Direi que, se fosse adicionar isso, a única coisa que consideraria
algo como # | | # ou # () #, uma vez que se aninham e não entram em conflito com
Arte ASCII feita de #, que deve ser suportada :)

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/JuliaLang/julia/issues/69#issuecomment -10911146.

É uma tradição de design de linguagem ter debates incrivelmente longos sobre a sintaxe dos comentários :)

#| e |# seriam especialmente interessantes se pudéssemos fazer #|# por um comentário "independente". Isso permitiria alternar os comentários digitando (ou apagando) apenas dois caracteres.

comentário inline:
f(x, #| y, |# z)
comentário inline desativado:
f(x, #|# y, #|# z)

comentário multilinha:

foo()
#|
for i = 1:3
  #|
     # baz()
     baz2()
  |#
     buzz()
end
|#

comentário multilinha desativado:

foo()
#|#
for i = 1:3
  #|
     # baz()
     baz2()
  |#
     buzz()
end
#|#

a propósito, outros caracteres simétricos podem ser interessantes, como : (que acho mais atraente visualmente) ou * (que toma emprestado de // e /* ... */ model)

Na verdade, eu meio que gosto disso:

#=
  Comment here
=#

Sente-se levemente inspirado por POD e funciona bem com arte ASCII, por exemplo, #======== . Poderíamos permitir #=# como um comentário de fechamento automático.

Em 1 de dezembro de 2012, 19h05, "Stefan Karpinski" [email protected] escreveu:

Na verdade, eu meio que gosto disso:

=

Comente aqui
= #

Sente-se levemente inspirado por POD e funciona bem com arte ASCII, por exemplo

========. Poderíamos permitir # = # como um comentário de fechamento automático.

+1

1 para o PHP-ification dos comentários de Julia.

O que é PHP-ification? O PHP faz isso para comentários de várias linhas?

Pergunta acidental. Se você deseja ter comentários de várias linhas, provavelmente parte do objetivo é ser capaz de comentar trechos arbitrários de código. Isso falha se você tiver um caractere de comentário de fechamento em uma string ou comentário final. Se tornarmos os comentários aninhados, abrir comentários em strings e comentários finais também será um problema. Exemplo:

#=
"=#"
# =#
=#

Portanto, a questão é como reconhecemos a sintaxe para fazer comentários de várias linhas? Minha inclinação é torná-lo bastante consciente para que todas essas coisas "simplesmente funcionem", mas isso com certeza é muito mais complicado.

ou sua versão inspirada em juila: ~)

~

  comment here

~ #

permitindo # ~ # como um comentário de fechamento automático

No sábado, 1º de dezembro de 2012 às 13h09, John Myles White
notificaçõ[email protected] :

1 para o PHP-ification dos comentários de Julia.

-
Responda diretamente a este e-mail ou visualize-o em Gi tHubhttps: //github.com/JuliaLang/julia/issues/69#issuecomment -10920019.

PHP não faz isso com comentários. Eu estava apenas comentando sobre a semelhança visual com os modelos HTML no estilo PHP com entradas <%= =%> .

Certo, certo. Eu realmente gosto de #= ... =# que é estranho porque, por algum motivo, parece que odeio a maioria das propostas de comentários em várias linhas.

Devo dizer que, de todas as alternativas que vi, gosto mais de #= ... =# .

=

 well, wrap me up in
 #=  and call me  =#
 comfortably swathed

= #

No sábado, 1º de dezembro de 2012 às 21h43, Viral B. Shah [email protected] :

Devo dizer que de todas as alternativas que vi, gosto de # = ... = # o
a maioria.

-
Responda diretamente a este e-mail ou visualize-o em Gi tHubhttps: //github.com/JuliaLang/julia/issues/69#issuecomment -10925287.

@StefanKarpinski; é um problema fazer com que o analisador descubra o que é uma string antes de descobrir o que é um abridor / fechado de comentário?

É possível, mas é um pouco estranho porque significa que strings dentro de comentários seriam significativas. Então, você está analisando o conteúdo dos comentários. Pensando bem, talvez isso deva ser integrado à funcionalidade stringish do documento.

= = # me lembra do esforço extra (ler, membros e pensar emacs) que requer, ao contrário de dizer, o simples símbolo primo '' ': http://en.wikipedia.org/wiki/Prime_%28symbol%29 # Use_in_mathematics.2C_statistics.2C_and_science

Quais seriam as armadilhas de usar '' '' '' como uma docstring?

Não me importo muito com o formato usado, mas quero votar a favor dos comentários de várias linhas. Embora seu uso como docstrings pareça difícil, visto que muitos métodos julia são definidos como casos especiais de outros métodos como f(a,b,c) = f((a,b), d(c))

Que tal usar uma macro <strong i="5">@comment</strong> begin ..... end vazia para comentários em várias linhas?

macro comment(b) end

O problema é que o bloco de comentário precisa estar sintaticamente correto, mas isso é bom se você deseja ignorar parte do seu código para teste.

Que tal unificar comentários de linha única e blocos. O caractere de comentário # pode ser usado para indicar o início de ambos os tipos de comentários e resulta em um comentário de uma linha se não for seguido por uma tag de encerramento, por exemplo, /# .

Exemplos:

# This is a single-line comment.

# This is a block comment,
  consisting of two lines. /#

# Block comments are a useful tool
foo(a, #b,/# c)

As vantagens são que ele não depende de espaços em branco, o que é consistente com o resto de Julia, permite comentários aninhados e sua natureza unificada permite comentar com eficiência um bloco de código inteiro digitando dois caracteres. Por exemplo:

# This is an example code block
foo()
bar()

é rapidamente anulado por

# This is an example code block
foo()
bar() /#

Parece que os comentários de várias linhas são normalmente usados ​​por um de dois motivos:
caso 1: documentação do código
caso 2: apagando blocos de código

Em relação ao caso 1, talvez seja melhor escolher uma sintaxe que você sabe que será amigável ao gerador de documentos ou fornecer um mecanismo dedicado como strings de doc do Python. (Na verdade, sou a favor do último, mas essa é apenas minha opinião.)

Em relação ao caso de uso 2, esse uso deve ser realmente encorajado? Temos controle de versão, o que permite que uma pessoa exclua blocos de código, documente cuidadosamente por que o fizeram e, em seguida, reverta essa ação se necessário. Temos macros, que podem potencialmente ativar / desativar mecanismos de depuração, como asserções e instruções de impressão de forma mais elegante do que comentários de várias linhas.

Python fornece dois mecanismos diferentes para esses dois casos:

1. expressões literais de string para documentação de código, que podem ser multilinhas com aspas triplas ( """ ou ''' )
2. # para eliminar blocos de código, que não podem ser multilinhas (mas são facilmente feitos em blocos pelos editores)

Essa abordagem tem vantagens para cada caso:

1. strings de documentação são visualmente distintas do código comentado, especialmente com destaque de sintaxe
2. é visualmente óbvio qual código está apagado, mesmo sem realce de sintaxe

Não há problema em usar um operador simétrico """ para docstrings de várias linhas, já que eles não precisam ser aninhados.

Se um operador assimétrico para comentários multilinhas for realmente desejado, recomendo algo cuja direção seja visualmente muito óbvia: não é para #| |# ou #= =# , mas é para <# #> .

Eu escolheria <# #> vez de #( )# ou (# #) pois os parênteses têm seu próprio significado de matchfix e podem ser interpretados visualmente como separados.

<#
  function foo(n)
  """
  foo docstring
  """
    # return 1    # blanked out
    "returns zero"
    return 0
  end
#>

Se literais de string comuns "..." são permitidos como docstrings, o usuário precisa evitar torná-los a última expressão em uma função (daí o valor de retorno). Como a maioria das docstrings se referem ao código a seguir, essa restrição parece boa e mantém todo o comportamento consistente.

<# é o identificador < seguido por um comentário de linha, então isso não funcionará. Eu diria que algo como #= =# é razoavelmente intuitivo, uma vez que todos os comentários começam com # .

A intuitividade de <# é discutível - eu li isso como o marcador de fechamento do par, como em #> comment <# - que na verdade funcionaria como um par delimitador de comentário. Ainda gosto de #= comment =# melhor.

O final de #| |# também começa com um identificador, mas eu estava assumindo uma análise especial para comentários.

A ambigüidade direcional de <# #> não me ocorreu. Não consigo pensar em outro símbolo QWERTY direcional claramente que ainda não seja usado na sintaxe matchfix, então talvez ele esteja lá.

Só para constar, não estou convencido de que comentários multilinhas sejam uma boa ideia, dada a vantagem 2 mencionada acima. Python parece ser mais limpo sem eles.

Mas Python tem docstrings, que são basicamente como comentários de várias linhas. A não localidade que eu pessoalmente não gosto em comentários de várias linhas é replicada por docstrings.

Sempre achei que doc strings em python estão um pouco erradas. Por que não posso simplesmente ter uma string no contexto vazio? Essa é uma expressão perfeitamente válida, embora de utilidade limitada. Há também um monte de questões problemáticas que não surgem no Python, mas surgem em Julia, que é muito mais liberal com strings - como Ruby ou Perl:

• O que acontece se houver interpolação dentro de uma string doc?
• E se essa interpolação tiver efeitos colaterais?
• E se a interpolação depender de argumentos da função?
• Como você avalia a string doc sem valores para o argumento?
• Ou é apenas uma string no contexto vazio e não um documento se não contiver interpolações?
• Ou é um erro ter interpolação em algo que pode ser interpretado como uma string doc?
• E se a string doc for a última expressão na função?
• Isso significa que não posso retornar implicitamente uma string de várias linhas usando interpolação?

Eles não aparecem no Python porque o Python não tem interpolação e requer retornos explícitos.

function imamonster!(arg)
  """
  imamonster! – $(arg)!
  $(println("Hello, world."))
  """
end

Se você deseja uma documentação embutida, não há realmente nenhuma vantagem em roubar uma forma de expressão válida em vez de usar uma convenção de comentário específica. Se você usar uma convenção de comentários, pelo menos se não estiver ciente da convenção, você não interpretará nada errado, apenas não estará ciente da documentação.

@johnmyleswhite - você pode elaborar sobre a questão da não localidade?

Para mim, a não localidade parece boa para docstrings porque (a) o leitor pode facilmente distingui-los do código e (b) eles não estão aninhados. Apenas olhando para eles, o leitor sabe que eles nunca são executados, e pode ver visualmente a que região pertencem.

A não localidade é um problema com o código comentado de várias linhas, porque apenas olhar para uma linha de código não diz se ele foi executado ou não, nem a que região pertence.

Stefan, não localidade significa apenas que você não pode analisar uma única linha sem ver algo que pode ter acontecido centenas de linhas antes. Isso acontece muito em bibliotecas para Python, onde as docstrings se estendem por muitas páginas.

Thomas, você está definitivamente certo: é possível para a maioria das linhas determinar que não são código, embora o exemplo ocasional que desliza em uma docstring às vezes interrompa isso. O que me deixa louco é que as docstrings introduzem uma região com espaços em branco ad hoc, o que torna muito difícil manipulá-los usando coisas como multicursores.

De qualquer forma, muitas pessoas querem comentários de várias linhas (que têm esse estranho problema de interpretação), então devemos escolher um delimitador lógico e implementá-los.

Só de olhar para eles, o leitor sabe que nunca são executados,

Como é isso? Uma string é uma expressão perfeitamente válida em Julia com um valor válido que resulta quando ela é executada. Isso também é verdade em Python, btw, e é por isso que sempre achei que as strings de doc eram um pouco incompletas.

O final de # | | # também começa com um identificador, mas eu estava assumindo uma análise especial para comentários.

O fim de fechamento começando com um identificador não é um problema - é o fim de abertura para o qual é um problema.

Uma string é uma expressão perfeitamente válida em Julia com um valor válido que resulta quando ela é executada. Isso também é verdade em Python

Acredito que o compilador Python otimiza os literais de string isolados, portanto, eles estão efetivamente ausentes.

Se você usar uma convenção de comentários, pelo menos se não estiver ciente da convenção, você não interpretará nada errado, apenas não estará ciente da documentação.

Talvez eu tenha entendido mal, mas eu teria dito o contrário: se você usar literais de string como docstrings, então (exceto para o caso da última expressão em uma função) você interpretará o programa corretamente, mesmo que não esteja ciente da convenção , embora não tenha conhecimento da documentação. Se você usar sintaxe adicional, deve estar ciente dela para interpretar o programa corretamente.

O final do fechamento começando com um identificador não é um problema

Como eu disse, eu estava considerando isso do ponto de vista da usabilidade e legibilidade, supondo que o analisador trataria essas combinações de maneira especial. Se uma linha de código terminar com o identificador | , iniciar um comentário de uma única linha imediatamente após seria semelhante ao |# fechamento.

O que o compilador faz ou não otimiza é irrelevante para a semântica da linguagem - caso contrário, não seria uma otimização, seria uma parte semanticamente significativa da linguagem.

O que eu quis dizer é que se a documentação literária for fornecida como um tipo especial de comentário, como:

# foo(x) – compute the foo transform of `x`
#
function foo(x)
  # do stuff
end

Por exemplo, digamos que a convenção é que os comentários que levam diretamente a uma definição de função ou método estão associados a eles como documentação, então esses dados claramente não afetam a execução, pois mesmo que você não saiba nada sobre comentários de documentos, ainda é claramente um Comente.

De qualquer forma, as strings de doc do Python são um obstáculo para Julia por causa de todos os problemas que listei acima.

O documento de estilo de codificação do kernel do Linux (https://www.kernel.org/doc/Documentation/CodingStyle) afirma que o estilo preferido para comentários longos (várias linhas) é:

/*
 * This is the preferred style for multi-line
 * comments in the Linux kernel source code.
 * Please use it consistently.
 *
 * Description:  A column of asterisks on the left side,
 * with beginning and ending almost-blank lines. 
 */

Eu também vi isso em muitos outros projetos C e C ++. Parece que me lembro de ter lido um guia de estilo C ++ recomendando que // seja usado para todos os comentários (incluindo comentários de várias linhas), mas não consigo encontrar a referência agora. O documento do Linux não fornece a justificativa; entretanto, geralmente acabo fazendo isso para que, quando o caractere / * inicial rolar para fora da tela em uma longa seção de comentário, fique claro que estou olhando para um bloco de comentário. (Talvez seja isso que @johnmyleswhite queria

O ponto aqui é que C fornece comentários de várias linhas, mas muitos programadores C realmente não os usam dessa forma.

Com base nisso, estou inclinado a inferir o seguinte sobre os futuros programadores de Julia: Se Julia fornecer suporte a comentários de várias linhas (o equivalente a / * * /), um subconjunto não trivial de usuários de Julia simplesmente não o usará . O que significa que, quando chegar a hora de compor um projeto usando vários pacotes, teremos uma mistura de formatos de comentários de várias linhas. Ou seja, veremos

/*
 * stuff like
 * this
 */

e

/*
stuff like
this
*/

Como observação lateral, uma coisa boa sobre / * * / comentários é a capacidade de inserir comentários; por exemplo

int foo(x, /* doc meaning of x */
          y, /* doc meaning of y */
          z, /* doc meaning of z */);

Claro, neste exemplo, / * * / não estão sendo usados ​​como comentários "multilinhas", mas algo diferente ("comentários inline"?).

Coffeescript tem o bom

#

bla

#

http://coffeescript.org/#strings

Em quinta-feira, 5 de setembro de 2013 às 20h37, Benjamin Silbaugh
notificaçõ[email protected] :

O documento de estilo de codificação do kernel Linux (
https://www.kernel.org/doc/Documentation/CodingStyle) afirma que o
o estilo preferido para comentários longos (várias linhas) é:

/ *

• Este é o estilo preferido para multilinhas
• comentários no código-fonte do kernel Linux.
• Use-o de forma consistente.
  *
• Descrição: uma coluna de asteriscos no lado esquerdo,
• com início e fim de linhas quase em branco.
  * /

Eu também vi isso em muitos outros projetos C e C ++. Parece que me lembro
lendo um guia de estilo C ++ recomendando que // seja usado para todos os comentários
(incluindo comentários de várias linhas), mas não consigo encontrar a referência
agora mesmo. O documento do Linux não fornece a justificativa; entretanto, eu
geralmente acabam fazendo isso de forma que quando o caractere / * principal rola para fora
a tela em uma longa seção de comentários, ainda está claro que estou olhando
um bloco de comentário. (Talvez seja isso que @johnmyleswhitehttps : //github.com/johnmyleswhite

O ponto aqui é que C fornece comentários de várias linhas, mas muitos C
os programadores não os usam realmente dessa forma.

Com base nisso, estou inclinado a inferir o seguinte sobre a futura Julia
programadores: Se Julia fornecer suporte a comentários de várias linhas (o equivalente
de / * * /), um subconjunto não trivial de usuários Julia simplesmente não vai usar
isto. O que significa que quando chega a hora de compor um projeto usando vários
pacotes, teremos uma mistura de formatos de comentários de várias linhas. Ou seja, vamos
Vejo

/ *

• coisas como
• esta
  * /

e

/ *
coisas como
esta
* /

Como uma observação lateral, uma coisa boa sobre / * * / comentários é a capacidade de
comentários inline; por exemplo

int foo (x, / * doc significado de x _ /
y, / _ doc significado de y _ /
z, / _ doc significado de z * /);

Claro, neste exemplo, / * * / não estão sendo usados ​​como "multilinhas"
comentários, mas algo diferente ("comentários embutidos"?).

-
Responda diretamente a este e-mail ou visualize-o em Gi tHubhttps: //github.com/JuliaLang/julia/issues/69#issuecomment -23911810
.

Dr. Rahul Dave
ADS, Center for Astrophysics
Universidade de Harvard
[email protected]
(રાહુલ દવે)

E fechamos o círculo. Estou pensando em encerrar o problema agora e fingir que era apenas um troll épico o tempo todo.

+1 para # = = #, pois é a seleção preferida pelos seletores e seria melhor decidida antes de fechar

Oi,

Eu sou novo para Julia, então esta pergunta pode demorar um pouco. Mas talvez ainda seja relevante. Você consideraria adicionar um mecanismo para comentar um bloco inteiro, por exemplo, algo análogo ao "#;" de Scheme? Ou seja, um operador - vamos chamá-lo de "@ #" - de modo que

@# início
...
fim

comentaria todo o bloco (e da mesma forma para outros tipos de estruturas de bloco). Frequentemente acho isso útil na depuração.

@ # é apenas a primeira ideia que surgiu, pois parece que o comportamento dessa coisa é semelhante a macro. Na verdade, pode-se facilmente escrever uma macro que substitui um determinado bloco por algo inócuo, embora isso não seja muito correto semanticamente se o bloco em questão vier no final de, digamos, uma definição de função. Além disso, alguma forma disso pode ser útil dentro de expressões matemáticas, embora naturalmente haja algumas ambigüidades que teriam que ser resolvidas, e isso seria difícil de fazer com uma macro.

Se isso já foi discutido em outro lugar, ou de fato discutido e rejeitado, por favor me avise. Desculpe prolongar esta longa discussão. :-)

Felicidades,
KL

1 para comentários de várias linhas. Qualquer escolha está bem!

Observe que as pessoas que estão tendo dificuldade com comentários em várias linhas apareceram duas vezes na lista de discussão nos últimos dias. O que é pior é que algumas pessoas estão começando a definir macros ou usar quote para emular isso, o que parece uma monstruosidade que devemos evitar.

Claramente, os editores ainda não são bons o suficiente. Ou os usuários não são bons o suficiente para escolher / usar seu editor, o que é um problema mais difícil de resolver.

O consenso parece ser #? ... ?# para alguma escolha de ? . Tanto | quanto = parecem razoáveis ​​para ? . Minha preferência seria que ? fosse uma forma de colchete, por exemplo, #{ ... }# (um aceno para Pascal), para tirar vantagem da correspondência de chave do editor.

(A atratividade dos comentários de várias linhas não é uma grande preocupação para mim. Na verdade, eu chamaria os comentários de várias linhas não atraentes de um recurso, não de um bug: isso é algo que deve ser usado para hacks de depuração rápida, enquanto para documentação permanente eu ainda preferiria incentive um prefixo # em cada linha para distinguir visualmente os comentários do código.)

Muitas das questões de ambigüidade discutidas acima têm a ver com a distinção entre um operador de comentário multilinha proposto, por exemplo

#{ ...code commented out... }#

e uma combinação de comentários de uma linha com código válido

#{ ...array at end of line, commented out... }# documentation comment .

Pode ser tarde demais, mas e se comentários de uma linha forem _necessários_ para deixar um espaço (ou mais) após o caractere # ? Isso certamente não seria ruim para a legibilidade :-)

Na verdade, estou usando uma macro @# conforme sugerido por @kkylin , e descobri que é bom estendê-la a outros tipos de macros de "comentário" também: por exemplo, recentemente escrevi um par de macros para depuração, em que um envolve um bloco de código e, dentro dele, outro comenta efetivamente sua expressão de argumento, exceto quando o bloco encapsulado lança um erro (particularmente útil para loops de depuração, embora o meu ainda não seja totalmente robusto).

A única limitação significativa da abordagem macro é comentar as formas arbitrárias dentro das expressões, o que sugere macros lidas.

Clojure usa esse sistema como padrão:

• comentários de uma linha / resto de linha com um único caractere ( ; )
• comentários de expressão inteira com uma macro ( comment , que avalia como nulo)
• comentários de forma arbitrária com uma macro de leitura ( #_ , que efetivamente desaparece, geralmente usado com "..." envolvendo o código comentado)

Este sistema em conjunto parece fornecer suporte fácil para todos os casos de uso descritos neste tópico (incluindo comentários embutidos), com extensibilidade para usuários avançados.

O problema https://github.com/JuliaLang/julia/issues/455#issuecomment -4178835 levantou o espectro de problemas de realce de sintaxe contra macros de leitura, mas pelo menos um editor Clojure parece suportar o realce de sintaxe para #_ ler macro [1]. Eu não usei, mas talvez este seja um caso especial?

[1] http://code.google.com/p/counterclockwise/issues/detail?id=109#c2

Julia não leu macros, mas você pode comentar texto arbitrário com um literal de string não padrão:

macro comment_mstr(x) end

comment"""
Not parsed or interpolated.
"""

Não estou totalmente convencido de que isso precisa estar na Base, no entanto.

Outra opção não totalmente séria: → e ←.

O caso de uso mais importante, IMO, não são comentários em várias linhas, mas comentários _inline_. Usar aspas e macros realmente não funciona muito bem neste caso. Ainda apoio #= ... =# mas alguém precisa implementá-lo.

você pode comentar texto arbitrário com um literal de string não padrão

A diferença é que uma macro vazia é avaliada como nothing , portanto, não satisfaz muitos dos casos de uso, por exemplo:

(x, comment"y," z) => erro

foo() = option(1) comment"option(2)" => erro

begin
foo()
comment"optional()"
end

=> nada

O mesmo é verdade para a macro comment em Clojure, que é a razão para a macro de leitura.

Eu gosto de @ #, mas pode ser mais digitação do que as pessoas gostam.

Meu um centavo é aquele

#

multilinha
Comente

#

Seria ruim para mim e possivelmente para outras pessoas. Eu uso sem pensar #, ##, ###, ou qualquer número de #s quando estou comentando coisas, baseado em quão bom parece ## é muito popular. Acho que pode causar comportamentos estranhos se esse tipo de coisa for comum.

Só queria expressar que também gosto muito de #= ... =# e, para comentar blocos de código maiores, isso seria muito útil. Infelizmente, meu lisp foo não existe, então não posso ajudar na implementação.

Conforme mencionado em # 6132 e # 6444, a sintaxe #= .... =# está se mostrando um tanto irritante na prática porque # pode iniciar um comentário de uma única linha ou um comentário de várias linhas.

Que tal %= ... =% vez disso? Há algum precedente para % como um caractere de comentário (Matlab), % nunca é usado antes ou depois de = no código Julia válido atual e as estatísticas em # 6128 sugerem que % raramente é usado no código Julia de qualquer maneira.

Tecnicamente %= é um operador.
Faz sentido para mim usar # pois já está associado a comentários.

Que tal usar o provavelmente removido #=# ? Isso torna os comentários de várias linhas mais difíceis de usar, mas diminuiria substancialmente a probabilidade de você criar um comentário de várias linhas por acidente.

Os comentários em várias linhas geralmente vêm em pares e não há correspondência para #=# .

Eu acho que ninguém jamais admitiria o uso de #=#= como o início do comentário.

A sequência de início do comentário de várias linhas atual quebrou muitos códigos que eu escrevi que se pareciam com:

#=============
# Comment
#=============

Já que empreguei um monte de outros blocos de comentários semelhantes com #--- ou #### , espero não superá-los no futuro.

Ok, nada em %= .. =% então. Estou ficando sem ideias sensatas.

@johnmyleswhite você acha que #___ e ___# também alterariam os padrões de formatação comuns?

Certamente parece raro que sublinhados triplos ocorram como prefixos de nomes de variáveis ​​(não ocorre na base, como sublinhados simples e duplos).

É relativamente difícil contar os sublinhados visualmente para distinguir #__ de #___ , pelo menos na minha fonte. A outra possibilidade mencionada em # 6128 era #% ... %# , que é meio feio e ninguém gosta disso, mas parece relativamente improvável de colidir com comentários de linha única (provavelmente precisamente porque é feio, combinado com o fato de que % raramente é usado).

Ou podemos apenas ficar com o #= ... =# original de Stefan. Pareceu valer a pena revisitar agora que as pessoas tiveram a chance de experimentá-lo, antes de ser gravado na pedra (bem, no barro pelo menos) na versão 0.3.

Acho que ficar com #= é uma boa ideia, e os usuários simplesmente não precisam ter um código como o de @johnmyleswhite acima. Nós apenas temos que evitar uma sintaxe que poderia causar comentários ingênuos para criar um comentário de bloco, (por exemplo, #{ poderia surgir de ter um Any dict sendo definido no início da linha) e #= parece fazer isso muito bem para mim.

É realmente difícil contar sublinhados para distinguir #__ de #___ .

Não parece tão difícil se você é o único digitando (você pode sentir e vê-los aparecer), e nenhum leitor praticamente precisaria distinguir os dois.

Se você desistir da direcionalidade visualmente óbvia, não vejo nenhuma boa razão para não ser Lisp-y e ir com #| e |# --- as estatísticas de frequência inicial para | vs. % na base (https://github.com/JuliaLang/julia/pull/6128#issuecomment-37433857) são diferentes principalmente porque as definições para % são escritas usando rem .

Pode ser OK ir com #= , desde que um aviso seja impresso quando #== for encontrado. Seria uma pena que, para um recurso tão pequeno como comentários de várias linhas, algumas pessoas caíssem em erros estranhos ao desenhar cabeçalhos de arte ASCII, como em https://github.com/JuliaLang/julia/issues/69#issuecomment -39747985.

O problema do cabeçalho também pode ser resolvido exigindo um espaço em branco ao redor dos identificadores #= =# .

+1

Este é o pior recurso de todos os tempos.

Considere que os comentários em bloco podem ser valiosos nos blocos de código:
foo(x,y) = foo1(x) #|foo1 does ... |# + foo2(y) #|foo2 does ... |#

Eu sei que parece bobo, mas pode ser útil. Se for esse o caso, torná-lo um conjunto de dois caracteres é o ideal. A aparência do comentário lisp #| Your boxed in comment |# é muito bom para mim. Eu programei e comentei extensivamente com o Stata que usa /* ... */ e eu o acho feio e não intuitivo. Talvez em detrimento do meu código, mas por uma questão de legibilidade, eu saio do meu caminho no Stata, para não usar comentários em bloco porque eu acho isso muito feio.

Só estou pesquisando como fazer o que a EconometricsBySimulation mencionou. É muito complicado fazer alguns testes de código sem bloquear comentários.

Consulte # 6128. #= e =# foram adicionados como delimitadores de bloco de comentário na v0.3.

Acho que a sugestão de @simleb foi de longe a melhor de todas neste tópico.

Acho que o par # (# comentário #) # ficaria bem legal.

Benefícios:

• o caractere # faz com que pareça um comentário
• os parênteses tornam os símbolos de abertura e fechamento óbvios e concisos
• o último caractere # faz com que pareça melhor (quase simétrico), especialmente quando escrito em sua própria linha
  uma vez que os símbolos de abertura e fechamento são diferentes, eles devem ser fáceis de analisar e o aninhamento pode ser permitido
  >

O navio partiu com este assunto - é por isso que está fechado.

Ou estou ficando louco ou #= =# não funciona no jupyter. Não que eu goste de usar o jupyter, mas não consigo fazer a instalação do Juno / Sublime funcionar - mas estou divagando.

Ao construir uma função, há uma maneira de ter comentários de várias linhas que funcionam da mesma maneira que a função de ajuda e imprimir o necessário? E se estiver usando o jupyter como?

Comentários multilinha funcionam no jupyter, mas o realce de sintaxe não.

@KristofferC

Exatamente

certo então

EDIT: quanto mais eu penso sobre isso, menos necessário isso parece. Considerando que é realmente apenas usar Markdown. Era apenas um hábito.

Jupyter precisaria de um patch para o modo Julia codemirror. (Não acho que fosse uma prioridade alta, pois comentários de várias linhas raramente são usados ​​interativamente. Eles são principalmente para comentar blocos grandes em um arquivo.) Cc

Corrigir. Eu não acho que isso seja algo que eu poderia fazer por um tempo.

Como os comentários de linha e de várias linhas de aninhamento funcionam? Atualmente (0.5.0) o seguinte código é válido:

##=

No entanto, "envolvê-lo" em um comentário de várias linhas produz um código inválido:

`# =

=

= # `

Este é realmente o comportamento pretendido?

Provavelmente #= ##= =# deve ser válido; deve ser um patch de analisador direto. Você pode registrar um problema?

Comentários em várias linhas são nossa coisa favorita para trabalhar no analisador e uma característica-chave de Julia em geral, então tenho certeza de que

Oh, eu poderia ter entrado com um problema, mas nem tenho certeza se o código deve ser válido em primeiro lugar.
Eu estava apenas curioso e tentando descobrir se seria possível aninhar comentários de diferentes tipos.

Em particular: Um comentário de linha deve ser um comentário de linha dentro de um comentário de várias linhas? E um comentário de várias linhas deve ser um comentário de várias linhas dentro de um comentário de linha? Meu pressentimento pessoal responderia "não" em ambos os casos, porque do contrário você provavelmente teria problemas de "intervalos sobrepostos", o que certamente é uma coisa ruim (corrija-me se estiver errado - talvez haja uma maneira de evitar isso).

Nesse caso, o segundo hash no código não iniciaria um comentário de linha, mas seria apenas algum caractere sem significado especial, enquanto o segundo #= abriria um comentário de várias linhas aninhado (BTW, esse nome é bastante lamentável uma vez que um comentário de várias linhas obviamente não é necessário para abranger várias linhas; IMHO "bloquear comentário" teria sido uma escolha melhor) que seria fechado pelo encerramento =# , deixando assim as linhas múltiplas "externas" comentário não fechado. Portanto, Julia estaria certa em rejeitar o código.

Portanto, repito minha pergunta: existe uma "opinião oficial" sobre como tratar comentários aninhados de diferentes tipos?

#= pretende abrir um comentário que pode, mas não precisa, ocupar mais de uma linha.
=# pretende fechar um comentário aberto com #=
#= e =# estão emparelhados e os pares podem ser aninhados
[permitir que =# feche todos os blocos de comentários abertos arbitrariamente aninhados foi considerado e colocado de lado]

#= .. =# deve se comportar da mesma forma, independentemente de quaisquer caracteres de comentário inline # aparecerem antes, entre, depois .. ou em qualquer outro riff dispersivo (se bem me lembro) .

isso deve ser interpretado como um comentário,
agora não
(se você for RP, inclua isso)

   #=# comment #=#

Sigh, podemos simplesmente deletar este recurso?

Durante meus 2 anos e meio de Julia, basicamente nunca vi uma reclamação sobre isso. Apenas esqueça que existe?

Eu faria, mas as pessoas continuam comentando sobre esse assunto.

No entanto, comentários multilinhas são geralmente úteis. Uma vez que a sintaxe não é
ainda enraizado, ainda seria fácil substituí-lo por algo melhor.
Na sexta-feira, 10 de março de 2017 às 10:25 Stefan Karpinski [email protected]
escrevi:

Eu faria, mas as pessoas continuam comentando sobre esse assunto.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/JuliaLang/julia/issues/69#issuecomment-285697167 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AA8SvRthejzfJrysM9UaBlX437A65el7ks5rkWt-gaJpZM4AF2X9
.

Eu uso comentários de várias linhas e acho que eles são muito úteis.

@StefanKarpinski Exigimos anotação intercalável. Tapeçaria é um código.

Nosso octothorpe foi mais octo do que thorpe, três de um tipo em vez de um tipo de três.

# permanece a marca onde# -following] por meio de eol.

Para comentários e isolamento de código temporário, o contexto de comentários entre pares ignora quaisquer # s e eols. Esses contextos de comentário se sucedem, aninham-se e se desenrolam como parênteses. Acho que resta apenas um conflito livre e fácil de ver a alternativa ASCII.

[=

function ab(a, b)
    return a^b / b^a
end

=]