+1
Eu realmente gostaria de ver isso acontecer.
Mais legível como end usado para indexação.

+1
Em 27 de dezembro de 2013 13h06, "GaborOszlanyi" [email protected] escreveu:

+1
Eu realmente gostaria de ver isso acontecer.
Mais legível como fim usado para indexação.

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

Eu gosto dessa sugestão também.

Estou um pouco surpreso com a onda de apoio que isso está obtendo. Sempre achei que os operadores explicados eram muito mais intuitivos para o fluxo de controle, mas não percebi que a sensação era generalizada.

Eu não era um fã quando você fez essa proposta, mas devo dizer que, depois de pensar um pouco mais, ela também faz muito sentido para mim. Esses são realmente operadores de fluxo de controle, em contraste com todos os outros, que usam símbolos em vez de texto. Isso pode reduzir a confusão com & e | .

Notei que as linguagens que fornecem and e or (Perl, Ruby, Lua - para as que verifiquei) também fornecem not (Lua nem mesmo oferece ! ). Minha primeira reação é que eu não gosto disso, já que é redundante com ! . Mas talvez haja uma forte razão para essas línguas escolherem fazer isso.

Pessoalmente, gosto muito de not , mas não acho que mudar para not oferece algo como a redução da ambigüidade que usar and e or oferece.

not também não é uma operação de curto-circuito / fluxo de controle e sempre tenho dificuldade em interpretá-la no que diz respeito à associatividade. O único lugar que eu gosto em Pyhton é if not ... mas isso é porque eu o li como uma operação de fluxo de controle.

+1

Também pode ser adicionado XOR como curto-circuito?
E a versão de curto-circuito das versões invertidas (XNOR, NAND, NOR)?

XOR nunca causa curto-circuito. Os outros podem ser escritos trivialmente com ! mais os operadores and e or .

+1
Vou apontar que em Ruby, há uma confusão constante sobre && vs 'e' (http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/), então seria bom se tivéssemos em mente o raciocínio que Ruby usa para ter ambos os conjuntos de operadores e decidir se vale a pena confundir ou se && deve ser removido completamente em favor de 'e'.

Eu preferiria que and e or tivessem precedência superbaixa como eles têm em Perl e Ruby para que você possa escrever coisas como

k <= n and k *= 2

Às vezes, você deseja atribuir o resultado booleano a algo:

cond = f() && g()

O que parece entrar em conflito com isso.

Bem, é precisamente por isso que Ruby e Perl têm ambos os conjuntos de operadores com precedências diferentes. Não defendendo isso, mas apenas dizendo. Não tenho certeza de quão comum esse uso realmente é, enquanto o grep em nosso código revela muitos k <= n && (k *= 2) tipos de coisas.

Em primeiro lugar, também estou a favor de and e or .
Vejo que os quatro grupos de precedência mais baixos em Julia agora são

1. Tarefas incluindo += etc., := , => e ~
2. O operador ternário ?
3. ||
4. &&

Acho que isso faz sentido (não tenho certeza sobre ~ , mas isso não vem ao caso). and e or lógicos são úteis tanto como lado direito das atribuições quanto como condição de ? . Se você for usar uma atribuição ou operador ternário como argumento para and ou or , acho que você sabe que está fazendo algo incomum e que os parênteses estão em ordem.

A propósito, acho que muitas pessoas esperariam que uma linguagem que usa and e or para operações lógicas usaria not para negação lógica. Mas se tivermos um bom motivo para manter ! , isso pode ser normal. (Eu acho que ! não é estritamente apenas negação lógica, pelo menos se # 4892 for implementado for mesclado.)

Eu ficaria um pouco triste com not vez de ! , mas vou com o que quer que seja aqui.

Eu realmente não acho que not seja análogo - and e or são operadores de fluxo de controle, não funções, enquanto ! é apenas uma função.

Eu concordo com Stefan. A única coisa que not realmente o pega é não ter que usar tantos parênteses. Acho que é um problema separado.

Eu estava falando sobre as expectativas iniciais de novos usuários. Mas eu acho
parece haver uma boa razão para manter!

Eu gostaria de ser contrário. Muitos idiomas usam && e ||, incluindo todos os que usei com alguma regularidade, e esses estão sempre em curto-circuito. Com e / ou eu não teria nenhuma expectativa intuitiva se eles causariam um curto-circuito ou não. Eu também gosto de como && e || são claramente separados visualmente dos nomes e números das variáveis.

A tabela em http://en.wikipedia.org/wiki/Short-circuit_evaluation pode ter alguma relevância para esta discussão.

Como alguém vindo do mundo Python, estou surpreso por concordar com @GunnarFarneback. Ultimamente, descobri que as condicionais em inglês ( and , or , not ) geralmente me levam a escrever um código incorreto que ingenuamente espero que funcione (porque faz sentido em inglês) e, em seguida, coçar minha cabeça por alguns segundos enquanto eu mentalmente converter de inglês para declarações lógicas antes de perceber meu erro. Dito isso, não sou particularmente tendencioso em nenhuma direção; apenas colocando meus 2 centavos.

Também defendo and e or

+1

+1
tem ambos os operadores
and e or com precedência fraca
Eu diria que cond = f() && g() deve ser escrito cond = (f() && g()) .
Também apóio o uso de not com precedência fraca com base em que ! , que tem precedência forte em todos os contextos que vi, requer if !(something and something) que não gosto em alguns nível, irracional e imutável. Também acho que ! é difícil de ver às vezes. Também ignoro a origem de ! mas sinto que tem um lugar mais legítimo como operador fatorial em números inteiros - portanto, uma preferência pela sintaxe ~ do matlab.

@johnmyleswhite este problema foi encerrado? Acho que o navio navegou neste.

:(

curto-circuito aquele rosto carrancudo

Acho que ainda devemos considerar isso. Muitas pessoas parecem não gostar de usar && e || da maneira como os estamos usando e prefeririam and e or . Há também a questão da precedência, que torna && e || um tanto estranhos. Poderíamos avançar para um futuro onde && e || exigem que ambos os operandos sejam booleanos e and e or façam o que && e || atualmente faz, mas com precedência inferior para que você possa escrever x == nothing and x = 0 e outros semelhantes. Isso ou introduzir uma sintaxe condicional de uma linha diferente como x = 0 if x == nothing .

A última sintaxe x = 0 if x == nothing tem alguns dos problemas IMO que a sugestão em https://groups.google.com/forum/#!topic/julia -dev / cnmLcNg8h0Q tem.
As duas opções a seguir são tão horríveis que Julia precisa de pós-condicionais?

    if x == nothing ; x = 0 ; end

ou

   x == nothing && (x = 0)

Dito isso, assim como eu não me importaria de ver uma construção repeat ; expr(s) ; until cond em Julia (mas posso viver sem ela), não vejo nada de errado em ter and e or adicionado a Julia.
Eles parecem se encaixar melhor com a sintaxe julia do que usar o emprestado de C && e || .

Acho que ainda devemos considerar isso.

+1

Fiquei surpreso pelo fato de a atribuição ter precedência inferior a || , então vim em busca de uma discussão anterior e encontrei esse problema. Não é grande coisa, mas esses parênteses parecem deslocados para mim. Levei um tempo (vários segundos, eu acho, e um teste no REPL) para descobrir qual local de atribuição era inválido. - A mensagem de erro indicou a linha após o final da definição da função.

isempty(o) || (m.over[s][NULL] = o)

Em contraste, os parênteses em cond = (f() && g()) parecem corretos para mim. Acho que os usaria de qualquer maneira.

Pelo que vale a pena, eu também preferiria and e or .

+1 de mim também.

A resposta é quase unanimemente positiva em favor de and etc. Eu conto duas opiniões contra, uma indiferente, um casal não especificado e todos os outros (15 ou mais) a favor.

Um argumento contra (mais difícil de ler), acho que está incorreto. O argumento é que foo and bar é mais difícil de ler do que foo && bar devido a 3 palavras vs palavra SÍMBOLO. No entanto, todos estão usando o realce de sintaxe e, neste caso, o inverso acontece. and é colorido como uma palavra-chave, então a<1 and b>3 irá realmente colorir em favor da divisão visual das subexpressões esquerda e direita, enquanto a<1 && b>3 todos os três operadores serão da mesma cor, sugestão de risco potencial de precedência do operador.

Um argumento _for_ que ainda não foi apresentado é que há uma consistência elegante para os operadores booleanos serem palavras, já que o resultado da operação é true ou false , ou seja, também uma palavra. Portanto, é muito fácil para um iniciante memorizar & vs and para bit a bit versus lógico. É muito mais difícil memorizar & vs && , pois parece uma atribuição arbitrária. Iniciantes garantidos usarão & incorretamente, pois & transmite a palavra and em inglês. Isso pode causar erros de precedência (?).

Outro possível argumento _for_ seria que o cérebro analisa naturalmente a palavra {BUNCH OF SYMBOLS} {BUNCH OF SYMBOLS}.

Por que não mudar? Agora é sempre a melhor hora para fazer isso, nunca vai ser mais fácil do que agora. Não é exatamente difícil consertar o código que usa atualmente &&.

Tenha and or not xor talvez nand apenas para completar ?? Não me importo com a ideia de ficar com ! . Deixe o programador escolher quando usar qual. Nada de errado com isso! Dito isso, ! já tem um uso em funções de estilo foo! , então há algum argumento "minimizar reutilização de símbolo".

@StefanKarpinski parece haver um consenso a favor desde 2013, eu poderia tentar implementar isso, mas estou preocupado se isso será considerado, uma vez que este problema não foi resolvido, presumo que ainda está aberto para discussão? Usar essas palavras em vez de símbolos vai ficar bem com isa sendo também um operador infixo, o mesmo que true , false , end , etc. Parece mais consistente e legível desta forma.

+1

Acabei de mudar para Julia do Python. Parece que Julia está em perigo de transbordar de símbolos. Por uma questão de código legível por humanos, apoio fortemente and e or

O suporte da palavra-chave not também pode melhorar a legibilidade do código.

Devemos descontinuar / proibir o uso de and e or (e possivelmente not ) em 0.7 / 1.0, respectivamente, para podermos adicioná-los mais tarde no caso de decidirmos realmente gosta deles?

Eu ficaria triste com isso. Aposto que @JeffBezanson é contra, mas se não permitirmos agora, podemos sempre mudar de ideia mais tarde e permitir, ao passo que não podemos ir na outra direção. Também pode ser útil ser capaz de fornecer uma mensagem de erro simples "Use && vez de and " para usuários que experimentam operadores no estilo Python.

Eu acho que isso seria ótimo!

Reabrindo e adicionando ao marco para garantir que não o esqueçamos.

Não entendo a intenção do marco, vamos adicionar and e or ? estamos reconsiderando isso? procurando outro uso disso? Ou você quer dizer que vai adicionar depreciação, como avisos, para que as pessoas que vêm de Python saibam usar && vez de and ?

Eu tinha https://github.com/JuliaLang/julia/pull/19788 em que eles eram aliases, mas posso mudar isso para substituí-los.

O marco deve significar: Chegue a uma decisão. Ou, se não conseguirmos chegar a uma decisão a tempo, cancele qualquer uso de and e or para que possamos adiar a decisão sem correr o risco de quebrar o código de ninguém mais tarde.

Eu entendo que dada a aspiração de congelar o código em algumas semanas, pode ser tarde demais para reabrir esta lata de vermes agora (e eu aprecio a ideia de adicionar depreciações para deixar a porta aberta para o futuro), mas um pensamento:

Quando isso surgiu pela primeira vez para discussão (2013), acho que a comunidade Julia era principalmente de desenvolvedores - pessoas com forte experiência em CS que estavam mais do que acostumadas a usar && e || . Eu _suspeito_ que as pessoas que podem apreciar and e or maioria são usuários aplicados que não se sentem tão à vontade com saladas ascii e que ainda não gastaram tempo suficiente em línguas mais antigas para se acostumarem totalmente com && e || . Pode ser interessante ver como as pessoas se sentem sobre isso se fizermos uma pesquisa com os usuários atuais do Julia (especialmente se trouxermos um discurso onde mais não desenvolvedores provavelmente verão).

O que foi proposto é reservar a sintaxe and , or e not . Se fizermos isso, podemos adicioná-los como operadores em qualquer ponto da linha do tempo 1.x. Nenhuma discussão adicional é necessária por enquanto.

Eu ficaria bem em analisá-los como erros de sintaxe permanentes, como fazemos com ** . Mas ainda sou muito, muito contra dar a eles qualquer tipo de significado de outra forma.

Também acho lamentável que estejamos desenterrando problemas antigos para os quais uma decisão já foi tomada, especialmente tão perto de 1.0.

Para ser claro: isso é feito se alguém o faz.

Obrigado pelo esclarecimento! : D

Parece-me muito bobo incomodar-se em analisá-los e proibir outro uso e, ainda assim, tornar isso um erro de sintaxe. Acho que a maioria das pessoas prefere não ter uma situação em que and e or sejam palavras reservadas (ou seja, não utilizáveis ​​em contextos como <strong i="7">@stackeval</strong> 1 0 and 1 or ), mas não fazem nada útil. Eu sugeriria que eles não fossem analisados ​​de forma alguma, ou fossem analisados ​​como apelidos (o que não é incomum, já que C e Ruby fazem isso).

Já decidimos não analisá-los como pseudônimos, por isso o PR foi fechado. Então, +1 por não analisá-los de forma alguma.

Correndo o risco de refazer esta discussão que foi tida ad nauseum, notarei que em relação a C e Ruby, usar and e or em C é muito incomum em minha experiência, e a maioria guias de estilo Ruby comuns requerem && e || vez de and e or .

IMHO: parece que os debates originais foram bastante divididos, e adicionar essa proteção simplesmente deixa espaço para a comunidade revisitá-la no futuro se ela quiser.

Não tenho ideia de por que isso foi reaberto.

Um dialeto de Julia com recursos sintáticos como este poderia ser feito usando JuliaParser.jl facilmente, uma vez que as APIs internas e de meta-programação se estabilizem, mal posso esperar por isso! :sorriso:

Para aqueles que abordaram este problema sem ter seguido o que aconteceu: Embora a ideia de usar and e or obtido uma boa quantidade de apoio *), o primeiro PR a abordar o problema - # 19788 - principalmente levou a uma discussão inconclusiva sobre se and e or deveriam ser substituições diretas de && e || ou deveriam ter semânticas ligeiramente diferentes, por exemplo, em relação para a precedência, mas apenas torná-los apelidos foi considerado indesejado. PR # 24965 teria reservado as palavras-chave (junto com not ), para permitir dar-lhes um significado durante o ciclo 1.x. No entanto, a discussão durante uma chamada de triagem resultou em desaprovação, portanto, o primeiro ponto em que isso poderia ser reconsiderado é para 2.0. (E provavelmente seria necessário apresentar um caso realmente convincente para que a mudança ocorresse então.)

*) Parece que a mudança proposta é menos popular entre os desenvolvedores mais influentes / "centrais", portanto, apenas olhar para o número de 👍s pode ser enganoso.

Espero não ter simplificado demais e ter feito as coisas decentemente certas. Peço desculpas se não o fiz.

portanto, o primeiro ponto em que isso poderia ser reconsiderado é para 2.0. (E provavelmente seria necessário apresentar um caso realmente convincente para que a mudança ocorresse então.)

Não vejo por que isso aconteceria se já decidimos várias vezes não fazer isso. Espero que possamos evitar desenterrar esse problema novamente para cada versão principal.

Se Julia permanecer por aqui por tempo suficiente para competir com Python, posso garantir que isso surgirá cada vez mais. Muitos usuários de Python não desejam retornar à sintaxe C. É uma das muitas razões pelas quais o Python é tão popular: fácil de aprender, viciante de usar, você não vai querer voltar à maneira antiga de fazer as coisas.

Os designers de novas linguagens frequentemente afirmam que desejam uma sintaxe amigável, mas tendem a se perder em recursos sofisticados que apenas um pequeno subconjunto de usuários irá querer ou usar, enquanto negligenciam ajustes simples que podem levar à adoção.

Caso em questão: os operadores Unicode bizarros são suportados , mas não a linguagem natural and e or .

R também usa && e || e indexação 1. Não é apenas mais antigo (ou linguagens de nível inferior como C). Eu sou indiferente a qual usar, mas não é mais difícil: eu ensinei R e Python para iniciantes (sem diferença de programação) e não é com isso que eles lutam. Normalmente, os conceitos subjacentes eram mais importantes e demoravam mais para serem aprendidos do que os símbolos ou palavras usados ​​para escrever o código. A sintaxe "amigável" e "intuitiva" para você como um usuário de R, Python, C, etc. será diferente simplesmente por causa do que você já conhece. Esse não é o caso para iniciantes absolutos, com os quais devemos nos preocupar mais aqui, pois acho que aqueles com experiência em programação em outras linguagens têm a experiência e o conhecimento para lidar com as diferentes convenções em uma nova linguagem.

A única razão que parece ter sido levantada aqui é que Python usa and e or e pessoas assim. Vale a pena mudar? Julia não é Python e não deveria tentar ser. Já temos Python. Para motivar qualquer pessoa a mudar para um novo idioma, deve ser diferente. Novos usuários de Julia podem não ser programadores de Python, eles podem ter experiência com uma linguagem diferente (ou nenhuma experiência se ela se tornar popular o suficiente).

Eu reconheço que este é provavelmente um problema morto, mas em resposta a @TomKellyGenetics , eu sugeriria que muitos de nós da IMHO argumentariam que R se qualifica como "mais velho" e não é particularmente amigável ... E embora eu concorde que com iniciantes, && Operadores de and , or ) mais familiares e legíveis, independentemente de serem Python usuários ou não.

R também usa && e || e 1-indexação. Não se trata apenas de linguagens mais antigas (ou de nível inferior) como C).

Eu estava me referindo a linguagens como o C, ou seja, linguagens que emprestam fortemente a sintaxe do C, geralmente com o argumento autorrealizável de 'é a sintaxe que todas as outras linguagens usam'. A sintaxe R é bastante semelhante a C, embora divirja aqui e ali. Julia é mais parecida com Fortran do que com C, embora haja alguma sobreposição.

Eu ensinei R e Python para iniciantes (sem diferença de programação) e não é com isso que eles lutam.

Alunos do IME novos em programação lutam com a sintaxe acima de tudo, é a morte por mil cortes. A programação é estranha, e escolher símbolos abstratos em vez da linguagem natural torna-a ainda mais estranha e fácil de esquecer. Costumo ouvir iniciantes em linguagens como o C perguntarem coisas como: "Como você escreve 'ou' de novo?"
Mas a linguagem natural na programação não é apenas um problema para iniciantes. Mesmo programadores experientes têm maior probabilidade de perder ! vez de not , e muitos acham mais fácil ler rapidamente e digitar or e and em || e && .

Julia não é Python e não deveria tentar ser. Já temos Python. Para motivar qualquer pessoa a mudar para um novo idioma, deve ser diferente.

Julia não é C nem Fortran. A grande maioria das linguagens populares é semelhante ao C, então se destacar geralmente significa fazer algo diferente de C. Na verdade, gosto de Fortran, C e seus descendentes, uso-os o tempo todo, mas em alguns lugares eles ficam aquém e acho que podemos Faça melhor. Usar uma linguagem mais natural é uma maneira. É importante notar que o Fortran 77 e superior usam .not. , .and. e .or. com bons resultados. Nesse sentido, eu realmente quero que Julia seja mais como Fortran, menos como C!

Este problema foi resolvido; and e or são permitidos como identificadores e continuaremos a usar && e || para controle de fluxo. Não sei por que isso ainda está sendo discutido.

Há uma tendência a superestimar a importância das questões superficiais de sintaxe, uma vez que são altamente visíveis, fáceis de discutir e suas implicações geralmente são claras. Em outra esfera, uma linguagem é considerada inutilizável, a menos que os blocos de código sejam cercados por chaves, caso em que julia e python estão além do limite.

Eu acho que é discutível se a and b é realmente mais legível do que a && b . && se destaca mais. O fato de || e && terem o mesmo comprimento também pode levar a uma formatação melhor. Uma das razões pelas quais símbolos de operador como a = b e a + b funcionam tão bem é que eles adicionam uma estrutura visual sobre algo como set a to b . a[i] ou element i of a ?

você não vai querer voltar à velha maneira de fazer as coisas.

Para mim, a maneira antiga de fazer as coisas é gerenciamento manual de memória e suporte fraco para polimorfismo, não a grafia de && .

Julia tem algumas expressões de linguagem natural, como for a in [1, 2, 3] . Esta leitura é melhor e é mais intuitiva do que for a = [1, 2, 3] , que Julia também suporta. Eu certamente não sugeriria que fornecêssemos alternativas de linguagem natural para todos os operadores simbólicos, apenas os poucos que tornam Julia mais intuitiva e legível.

FWIW, votei para adotar os dois conjuntos de operadores, para facilitar a adoção e dar aos usuários opções de estilo. Em projetos C ++ onde as pessoas usam ambos, isso nunca me incomodou. Não vejo mal nisso, apenas benefícios.

No geral, adoro a direção que a sintaxe de Julia tomou. Um ótimo equilíbrio entre linguagem natural e símbolos, provando que uma linguagem numérica pode se sobressair na programação de propósito geral. Mal posso esperar para ver como ele cresce e se desenvolve. O que é minha maneira de dizer que adicionar os operadores de linguagem natural é tecnicamente compatível com versões anteriores. :sorriso:

Vou tentar reservar or , and e not para um possível uso futuro e emitir um aviso / sugestão para usar os símbolos correspondentes. Devo fazer isso no Julia 0.7, 1.0 ou ambos?

24965?

Ah, perdi isso, obrigado! Acho que não reservar palavras-chave não impede o suporte a essas palavras-chave no futuro.

Desculpe, li toda a discussão, mas ainda não entendi. Como posso usar and , or na Julia agora?

Você não pode