+1
Realmente me gustaría que esto sucediera.
Más legible como end usado para indexar.

+1
El 27 de diciembre de 2013 13:06, "GaborOszlanyi" [email protected] escribió:

+1
Realmente me gustaría que esto sucediera.
Más legible como el final utilizado para indexar.

-
Responda a este correo electrónico directamente o véalo en Gi
.

También me gusta esta sugerencia.

Estoy un poco sorprendido por la oleada de apoyo que está recibiendo. Siempre sentí que los operadores detallados eran mucho más intuitivos para controlar el flujo, pero no me di cuenta de que la sensación era generalizada.

No era un fanático cuando hiciste esta propuesta, pero debo decir que después de pensarlo un poco más, también tiene mucho sentido para mí. Estos son realmente operadores de flujo de control, a diferencia de todos los demás, que utilizan símbolos en lugar de texto. Esto puede reducir la confusión con & y | .

He notado que los lenguajes que proporcionan and y or (Perl, Ruby, Lua - para los que he marcado) también proporcionan not (Lua ni siquiera ofrece ! ). Mi primera reacción es que no me gusta, ya que es redundante con ! . Pero tal vez haya una razón importante por la que estos idiomas optaron por hacerlo.

Personalmente, me gusta mucho not , pero no creo que cambiar a not ofrezca nada parecido a la reducción de la ambigüedad que proporciona el uso de and y or .

not tampoco es una operación de flujo de control / cortocircuito, y siempre me cuesta leerlo con respecto a la asociatividad. El único lugar que me gusta en Pyhton es if not ... pero eso se debe a que lo leo como una operación de flujo de control.

+1

¿También se puede agregar XOR como cortocircuito?
¿Y la versión de cortocircuito de las versiones invertidas (XNOR, NAND, NOR)?

XOR nunca puede cortocircuitarse. Los otros se pueden escribir trivialmente con ! más los operadores and y or .

+1
Señalaré que en Ruby, hay una confusión constante sobre && vs 'y' (http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/), entonces Sería bueno si tuviéramos en cuenta la lógica que usa Ruby para tener ambos conjuntos de operadores y decidir si vale la pena la confusión o si && debe eliminarse completamente en favor de 'y'.

Preferiría que and y or tengan una precedencia súper baja como lo hacen en Perl y Ruby para que puedas escribir cosas como

k <= n and k *= 2

A veces desea asignar el resultado booleano a algo:

cond = f() && g()

Lo que parece entrar en conflicto con eso.

Bueno, esa es precisamente la razón por la que Ruby y Perl tienen ambos conjuntos de operadores con diferente precedencia. No abogando por eso, sino simplemente diciendo. No estoy seguro de cuán común es ese uso en realidad, mientras que hacer grepping a través de nuestro código revela un montón de k <= n && (k *= 2) tipos de cosas.

En primer lugar, también estoy por and y or .
Veo que los cuatro grupos de precedencia más bajos en Julia en este momento son

1. Asignaciones que incluyen += etc., := , => y ~
2. El operador ternario ?
3. ||
4. &&

Creo que esto tiene sentido (no estoy seguro de ~ , pero eso no viene al caso). Los and y or lógicos son útiles como parte derecha de las asignaciones y como condición de ? . Si va a utilizar una asignación o un operador ternario como argumento para and o or , creo que sabe que está haciendo algo inusual y que los paréntesis están en orden.

Por cierto, creo que mucha gente esperaría que un lenguaje que usa and y or para operaciones lógicas use not para negación lógica. Pero si tenemos una buena razón para mantener ! , podría estar bien. (Supongo que ! no es estrictamente una negación lógica, al menos si se combina # 4892).

Estaría un poco triste por not lugar de ! , pero iré con lo que sea aquí.

Realmente no creo que not sea ​​análogo en absoluto: and y or son operadores de flujo de control, no funciones, mientras que ! es solo una función.

Estoy de acuerdo con Stefan. Lo único que not realmente consigue es no tener que usar tantos paréntesis. Creo que es un tema aparte.

Solo estaba hablando de las expectativas iniciales de los nuevos usuarios. Pero yo pienso
¡Parece haber una buena razón para poder mantener!

Me gustaría ser contrario. Un buen número de lenguajes usan && y ||, incluidos todos los que he usado con cierta regularidad, y siempre son cortocircuitos. Con y / o no tendría ninguna expectativa intuitiva si tienen un cortocircuito o no. También me gusta cómo && y || están claramente separados visualmente de los nombres y números de las variables.

La tabla en http://en.wikipedia.org/wiki/Short-circuit_evaluation puede tener cierta relevancia para esta discusión.

Como alguien que viene del mundo de Python, me sorprende encontrarme de acuerdo con @GunnarFarneback. Últimamente he descubierto que los condicionales en inglés ( and , or , not ) a menudo me llevan a escribir un código incorrecto que ingenuamente espero que funcione (porque tiene sentido en inglés) y luego tener que rascarme la cabeza durante unos segundos mientras me convierto mentalmente del inglés a declaraciones lógicas antes de darme cuenta de mi error. Dicho esto, no estoy particularmente predispuesto en ninguna dirección; solo pongo mis 2 ¢.

También estoy por and y or

+1

+1
tener ambos operadores
and y or con precedencia débil
Yo diría que cond = f() && g() debería escribirse cond = (f() && g()) .
También apoyo el uso de not con precedencia débil sobre la base de que ! , que tiene una fuerte precedencia en todos los contextos que he visto, requiere if !(something and something) que no me gusta en algunos nivel irracional e inmutable. También siento que ! es difícil de ver a veces. También ignoro el origen de ! pero siento que tiene un lugar más legítimo como operador factorial en enteros, por lo que prefiero la sintaxis ~ de matlab.

@johnmyleswhite ¿se cerrará este problema? Creo que el barco navegó en este.

:(

cortocircuito esa cara ceñuda

Creo que aún deberíamos considerar esto. A mucha gente parece no gustarle usar && y || la forma en que los estamos usando y preferirían and y or . También está la cuestión de la precedencia, que hace que && y || algo incómodos. Podríamos movernos a un futuro donde && y || requieran que ambos operandos sean booleanos y and y or hagan lo que && y || actualmente lo hacen pero con menor precedencia para que pueda escribir x == nothing and x = 0 y demás. O eso o introduce una sintaxis condicional de una línea diferente como x = 0 if x == nothing .

La última sintaxis x = 0 if x == nothing tiene algunos de los problemas, en mi opinión, que tiene la sugerencia en https://groups.google.com/forum/#!topic/julia -dev / cnmLcNg8h0Q.
¿Son las dos opciones siguientes tan horribles que Julia necesita post-condicionales?

    if x == nothing ; x = 0 ; end

o

   x == nothing && (x = 0)

Dicho esto, así como no me importaría ver una construcción repeat ; expr(s) ; until cond en Julia (pero puedo vivir sin ella), no veo nada malo en tener and y or agregó a Julia.
Parecen encajar mejor con la sintaxis de julia que usar prestado de C && y || .

Creo que aún deberíamos considerar esto.

+1

Me sorprendió que la asignación tuviera una precedencia menor que || , así que vine en busca de una discusión anterior y encontré este problema. No es gran cosa, pero esos paréntesis me parecen fuera de lugar. Me tomó un tiempo (varios segundos, creo, y una prueba en REPL) para averiguar qué ubicación de asignación no era válida. - El mensaje de error indicó la línea más allá del final de la definición de función.

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

En contraste, los paréntesis en cond = (f() && g()) parecen bien. Creo que los usaría de todos modos.

Por lo que vale, también preferiría and y or .

+1 de mí también.

La respuesta es casi unánimemente positiva a favor de and etc. Cuento dos opiniones en contra, una indiferente, un par sin especificar y todos los demás (15 o más) a favor.

Un argumento en contra (más difícil de leer) creo que es incorrecto. El argumento es que foo and bar es más difícil de leer que foo && bar debido a 3 palabras frente a la palabra SÍMBOLO. Sin embargo, todo el mundo utiliza el resaltado de sintaxis y, en este caso, ocurre lo contrario. and se colorea como una palabra clave, por lo que a<1 and b>3 realmente se coloreará a favor de dividir visualmente las subexpresiones izquierda y derecha, mientras que a<1 && b>3 los tres operadores serán del mismo color, cue potencial operador-precedencia-cabeza-rascado.

Un argumento _for_ que aún no se ha presentado es que existe una elegante coherencia en que los operadores booleanos sean palabras, ya que el resultado de la operación es true o false , es decir, también una palabra. Así que es muy fácil para un principiante memorizar & vs and para bit a bit versus lógico. Es mucho más difícil memorizar & && , ya que parece una asignación arbitraria. Los principiantes garantizados usarán & incorrectamente, ya que & transmite la palabra and en inglés. Esto podría causar errores de precedencia (?).

Otro posible argumento _para_ sería que el cerebro analiza naturalmente {BUNCH OF SYMBOLS} palabra {BUNCH OF SYMBOLS}.

¿Por qué no simplemente cambiar? Ahora es siempre el mejor momento para hacerlo, nunca va a ser más fácil que ahora. No es exactamente difícil arreglar el código que actualmente usa &&.

Tener and or not xor tal vez nand solo para completar ?? No me importa la idea de quedarme con ! . Deje que el programador elija cuándo usar cuál. ¡Nada de malo con eso! Dicho esto, ! ya tiene un uso en las funciones de estilo foo! , por lo que hay algún argumento de "minimizar la reutilización de símbolos".

@StefanKarpinski parece haber un consenso a favor que se remonta a 2013, podría intentar implementar esto, pero me preocupa si esto se considerará en absoluto, ya que este problema no se ha cerrado, supongo que aún está abierto para ¿discusión? El uso de estas palabras en lugar de símbolos funcionará bien con isa como operador infijo también, al igual que con true , false , end , etc. más coherente y legible de esta manera.

+1

Me estoy mudando a Julia desde Python. Parece que Julia está en peligro de desbordarse de símbolos. Por el bien del código legible por humanos, apoyo firmemente and y or

Admitir la palabra clave not también podría mejorar la legibilidad del código.

¿Deberíamos desaprobar / prohibir el uso de and y or (y posiblemente not ) en 0.7 / 1.0, respectivamente, para poder agregarlos más adelante en caso de que decidamos de hecho como ellos?

Estaría abajo con eso. Apuesto a que @JeffBezanson está en contra, pero si no permitimos ahora, siempre podemos cambiar de opinión más tarde y permitirlo, mientras que no podemos ir en la otra dirección. También puede ser útil poder dar un mensaje de error simple "Use && lugar de and " a los usuarios que prueben operadores de estilo Python.

¡Creo que sería genial!

Reabrir y agregar al hito para asegurarnos de que no lo olvidemos.

No entiendo la intención del hito, vamos a agregar and y or ? lo estamos reconsiderando? buscando otro uso de esto? ¿O quiere decir que va a agregar advertencias en forma de depreciación, para que las personas que vienen de Python sepan usar && lugar de and ?

Tenía https://github.com/JuliaLang/julia/pull/19788 en el que eran alias, pero puedo cambiar eso para reemplazarlos.

El hito debería significar: tomar una decisión. O, si no podemos tomar una decisión a tiempo, desaproveche el uso de and y or para que podamos posponer la decisión sin arriesgarnos a romper el código de nadie más adelante.

Entiendo que, dada la aspiración de congelar el código en unas pocas semanas, puede ser demasiado tarde para volver a abrir esta lata de gusanos ahora (y aprecio la idea de agregar depreciaciones para dejar la puerta abierta para el futuro), pero un pensamiento:

Cuando esto surgió por primera vez para la discusión (2013), creo que la comunidad de Julia eran principalmente desarrolladores: personas con sólidos antecedentes en informática que estaban más que acostumbradas a usar && y || . _Supongo_ que las personas que aprecian and y or son usuarios aplicados que no se sienten tan cómodos con las ensaladas ascii y que aún no han pasado suficiente tiempo en idiomas más antiguos para acostumbrarse por completo a && y || . Podría interesarle ver cómo se siente la gente al respecto si encuestamos a los usuarios actuales de Julia (especialmente si lo mencionamos en un discurso en el que es probable que lo vean más personas que no son desarrolladores).

Lo que se ha propuesto es reservar la sintaxis and , or y not . Si hacemos eso, podemos agregarlos como operadores en cualquier punto de la línea de tiempo 1.x. No se requiere más discusión por ahora.

Estaría bien con analizarlos como errores de sintaxis permanentes, como hacemos con ** . Pero todavía estoy muy, muy en contra de darles cualquier tipo de significado de otra manera.

También me parece desafortunado que estemos desenterrando viejos problemas para los que ya se ha tomado una decisión, especialmente tan cerca de 1.0.

Para ser claros: esto se hace si alguien lo hace.

¡Gracias por la aclaración! :D

Me parece muy tonto molestarme en analizarlos y prohibir otro uso y, sin embargo, convertirlo en un error de sintaxis. Creo que la mayoría de la gente preferiría no tener una situación en la que and y or son palabras reservadas (es decir, no se pueden usar en contextos como <strong i="7">@stackeval</strong> 1 0 and 1 or ) pero no hacen nada útil. Sugeriría que no se analicen en absoluto o que se analicen como alias (lo cual no es inusual, ya que C y Ruby hacen eso).

Ya hemos decidido no analizarlos como alias, por eso se cerró el PR. Entonces +1 por no analizarlos en absoluto.

A riesgo de repetir esta discusión que se ha tenido hasta la saciedad, señalaré que con respecto a C y Ruby, usar and y or en C es muy poco común en mi experiencia, y la mayoría Las guías de estilo comunes de Ruby requieren && y || lugar de and y or .

En mi humilde opinión: parece que los debates originales estaban bastante divididos, y agregar esta protección simplemente deja espacio para que la comunidad vuelva a visitarla en el futuro si les gustaría.

No tengo ni idea de por qué se volvió a abrir.

Un dialecto de Julia con características sintácticas como esta se podría hacer usando JuliaParser.jl fácilmente, una vez que las API internas y de metaprogramación se estabilicen, ¡no puedo esperar! :sonrisa:

Para aquellos que llegaron a este problema sin haber seguido lo que sucedió: aunque la idea de usar and y or reunió una buena cantidad de apoyo *), el primer RP en abordar el problema - # 19788 - condujo principalmente a una discusión no concluyente sobre si and y or deberían ser reemplazos directos de && y || o deberían tener una semántica ligeramente diferente, por ejemplo, con respecto a a la precedencia, pero el simple hecho de convertirlos en alias se consideró no deseado. PR # 24965 habría reservado las palabras clave (junto con not ), para permitir darles un significado durante el ciclo 1.x. Sin embargo, la discusión durante una llamada de triaje resultó en desaprobación, por lo que el punto más temprano en el que esto podría reconsiderarse es para 2.0. (Y probablemente sería necesario presentar un caso realmente convincente para que se produzca el cambio en ese momento).

*) Parece que el cambio propuesto es menos popular entre los desarrolladores más influyentes / "centrales", por lo que solo mirar el número de 👍 puede ser engañoso.

Espero no haber simplificado demasiado y haber hecho las cosas decentemente bien. Disculpas si no lo hice.

por lo que el punto más temprano en el que esto podría reconsiderarse es para 2.0. (Y probablemente sería necesario presentar un caso realmente convincente para que se produzca el cambio en ese momento).

No veo por qué sucedería alguna vez si hemos decidido varias veces ahora no hacerlo. Espero que podamos evitar desenterrar este problema nuevamente para cada lanzamiento importante.

Si Julia se queda el tiempo suficiente para competir con Python, puedo garantizar que esto surgirá cada vez más. Muchos usuarios de Python no quieren volver a la sintaxis C. Es una de las muchas razones por las que Python es tan popular: fácil de aprender, adictivo de usar, no querrás volver a la antigua forma de hacer las cosas.

Los diseñadores de nuevos lenguajes a menudo afirman que quieren una sintaxis fácil de usar, pero tienden a perderse en características sofisticadas que solo un pequeño subconjunto de usuarios querrá o usará, mientras pasan por alto los ajustes simples que podrían impulsar la adopción.

Caso en cuestión: se admiten operadores Unicode extraños , pero no el lenguaje natural and y or .

R también usa && y || y 1-indexación. No se trata solo de lenguajes más antiguos (o de niveles inferiores como C). Soy indiferente a cuál usar, pero no es más difícil: he enseñado tanto a R como a Python a principiantes completos (sin diferencia de programación) y esto no es con lo que lucharon. Por lo general, los conceptos subyacentes eran más importantes y tomaba más tiempo aprenderlos que los símbolos o palabras que se usaban para escribir el código. La sintaxis "fácil de usar" e "intuitiva" para usted como usuario de R, Python, C, etc. será diferente simplemente por lo que ya conoce. Ese no es el caso de los principiantes absolutos por los que deberíamos estar más preocupados aquí, ya que creo que aquellos con experiencia en programación en otros lenguajes tienen la experiencia y los conocimientos para manejar las diferentes convenciones en un nuevo lenguaje.

La única razón que parece haberse planteado aquí es que Python usa and y or y gente así. ¿Vale la pena la molestia de cambiar? Julia no es Python y no debería intentar serlo. Ya tenemos Python. Para motivar a cualquiera a cambiar a un nuevo idioma, debería ser diferente. Los nuevos usuarios de Julia pueden no ser programadores de Python, pueden tener experiencia con un lenguaje diferente (o ninguna en absoluto si se vuelve lo suficientemente popular).

Reconozco que probablemente sea un problema muerto, pero en respuesta a @TomKellyGenetics , sugeriría que en mi humilde opinión, muchos de nosotros argumentaríamos que R califica como "mayor" y no es particularmente fácil de usar ... Y aunque estoy de acuerdo en que con los principiantes, && operadores "no es con lo que lucharon", creo que la mayoría de los estudiantes a los que he enseñado encuentran operadores de idioma inglés ( and , or ) más familiares y legibles si son Python usuarios o no.

R también usa && y || y 1-indexación. No se trata solo de lenguajes más antiguos (o de nivel inferior) como C).

Me refería a lenguajes similares a C, es decir, lenguajes que toman prestada en gran medida la sintaxis de C, normalmente con el argumento autocumplido de "es la sintaxis que utilizan todos los demás lenguajes". La sintaxis de R es más bien similar a la de C, aunque diverge aquí y allá. Julia es más parecida a Fortran que a C, aunque hay cierta superposición.

He enseñado a R y Python a principiantes completos (sin diferencia de programación) y esto no es con lo que lucharon.

Los estudiantes de IME nuevos en programación luchan con la sintaxis además de todo lo demás, es la muerte por miles de cortes. La programación es ajena y la elección de símbolos abstractos sobre el lenguaje natural la hace aún más ajena y fácil de olvidar. A menudo escucho a los principiantes en idiomas similares a C preguntar cosas como, "¿Cómo se escribe" o "otra vez?"
Pero el lenguaje natural en la programación no es solo un problema para principiantes. Incluso los programadores experimentados tienen más probabilidades de perder un ! en lugar de un not , y a muchos les resulta más fácil leer rápidamente y escribir or y and sobre || y && .

Julia no es Python y no debería intentar serlo. Ya tenemos Python. Para motivar a cualquiera a cambiar a un nuevo idioma, debería ser diferente.

Julia tampoco es C ni Fortran. La gran mayoría de los lenguajes populares son similares a C, por lo que destacar generalmente significa hacer algo diferente de C. En realidad, me gusta Fortran, C y sus descendientes, los uso todo el tiempo, pero en algunos lugares se quedan cortos y creo que podemos hacerlo mejor. Usar un lenguaje más natural es una forma. Vale la pena señalar que Fortran 77 y versiones posteriores usan .not. , .and. y .or. con buenos resultados. En este sentido, realmente quiero que Julia sea más parecida a Fortran, ¡menos parecida a C!

Este problema ha sido resuelto; and y or están permitidos como identificadores y continuaremos usando && y || para el flujo de control. No estoy seguro de por qué todavía se está discutiendo esto.

Existe una tendencia a sobrevalorar la importancia de los problemas de sintaxis superficiales, ya que son muy visibles, fáciles de discutir y sus implicaciones suelen ser claras. En otra esfera, un lenguaje se considera inutilizable a menos que los bloques de código estén rodeados por llaves, en cuyo caso tanto julia como python están más allá de los límites.

Creo que es discutible si a and b es más legible que a && b . && destaca más. El hecho de que || y && tengan la misma longitud también puede conducir a un formato más agradable. Una de las razones por las que los símbolos de operador como a = b y a + b funcionan tan bien es que agregan estructura visual sobre algo como set a to b . a[i] o element i of a ?

no querrás volver a la antigua forma de hacer las cosas.

Para mí, la forma antigua de hacer las cosas es la gestión manual de la memoria y el soporte débil para el polimorfismo, no la ortografía de && .

Julia tiene algunas expresiones de lenguaje natural, como for a in [1, 2, 3] . Esto se lee mejor y es más intuitivo que for a = [1, 2, 3] , que Julia también admite. Ciertamente, no sugeriría que proporcionemos alternativas de lenguaje natural para todos los operadores simbólicos, solo los pocos que hacen que Julia sea más intuitiva y legible.

FWIW, voté a favor de adoptar ambos conjuntos de operadores, para facilitar la adopción y dar a los usuarios opciones de estilo. En proyectos de C ++ donde la gente usa ambos, nunca me ha molestado. No veo ningún daño en ello, solo beneficios.

En general, me encanta la dirección que ha tomado la sintaxis de Julia. Un gran equilibrio entre el lenguaje natural y los símbolos, lo que demuestra que un lenguaje numérico puede sobresalir en la programación de propósito general. No puedo esperar a ver cómo crece y se desarrolla. Cuál es mi forma de decir que agregar los operadores de lenguaje natural es técnicamente compatible con versiones anteriores. :sonrisa:

Intentaré reservar or , and y not para un posible uso futuro, y emitir una advertencia / sugerencia para usar los símbolos correspondientes. ¿Debo hacer esto en Julia 0.7, 1.0 o ambos?

24965?

¡Ah, me perdí eso, gracias! Supongo que no reservar palabras clave no impide admitir estas palabras clave en el futuro.

Lo siento, leí toda la discusión, pero aún no lo entendí, ¿cómo puedo usar and , or en Julia ahora?

No puedes