+1
J'aimerais vraiment que cela se produise.
Plus lisible comme end utilisé pour l'indexation.

+1
Le 27 décembre 2013 à 13h06, "GaborOszlanyi" [email protected] a écrit :

+1
J'aimerais vraiment que cela se produise.
Plus lisible comme fin utilisé pour l'indexation.

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/JuliaLang/julia/issues/5238#issuecomment -31280112
.

J'aime aussi cette proposition.

Je suis un peu surpris par la vague de soutien que cela suscite. J'ai toujours eu l'impression que les opérateurs énoncés étaient beaucoup plus intuitifs pour le flux de contrôle, mais je ne savais pas que le sentiment était répandu.

Je n'étais pas un fan lorsque vous avez fait cette proposition, mais je dois dire qu'après quelques réflexions, cela a aussi beaucoup de sens pour moi. Ce sont vraiment des opérateurs de flux de contrôle, contrairement à tous les autres, qui utilisent des symboles plutôt que du texte. Cela peut réduire la confusion avec & et | .

J'ai remarqué que les langages qui fournissent and et or (Perl, Ruby, Lua -- pour ceux que j'ai vérifiés) fournissent également not (Lua n'offre même pas ! ). Ma première réaction est que je ne l'aime pas, car c'est redondant avec ! . Mais peut-être y a-t-il une bonne raison pour laquelle ces langues ont choisi de le faire.

Personnellement, j'aime beaucoup not , mais je ne pense pas que le passage à not offre quelque chose comme la réduction de l'ambiguïté que l'utilisation de and et or offrent.

not n'est pas non plus une opération de court-circuit/flux de contrôle, et j'ai toujours du mal à savoir comment le lire en ce qui concerne l'associativité. Le seul endroit où je l'aime dans Pyhton est le if not ... mais c'est parce que je le lis comme une opération de contrôle de flux.

+1

Peut-on également ajouter XOR comme court-circuit ?
Et la version court-circuit des versions inversées (XNOR,NAND,NOR) ?

XOR n'est jamais court-circuitable. Les autres peuvent s'écrire trivialement avec ! plus les opérateurs and et or .

+1
Je ferai remarquer que dans Ruby, il y a une confusion constante entre && vs 'and' (http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/), donc ce serait bien si nous gardions à l'esprit le rationnel que Ruby utilise pour avoir les deux ensembles d'opérateurs et décider si cela vaut la confusion ou si && doit être complètement supprimé en faveur de 'et'.

Je préférerais que and et or aient une priorité très faible comme ils le font dans Perl et Ruby afin que vous puissiez écrire des choses comme

k <= n and k *= 2

Parfois, vous voulez affecter le résultat booléen à quelque chose :

cond = f() && g()

Ce qui semble en contradiction avec cela.

Eh bien, c'est précisément pourquoi Ruby et Perl ont les deux ensembles d'opérateurs avec une priorité différente. Ne pas plaider pour cela, mais juste le dire. Je ne sais pas à quel point cette utilisation est courante, alors que parcourir notre code révèle beaucoup de choses k <= n && (k *= 2) .

Premièrement, je suis aussi pour and et or .
Je vois que les quatre groupes de priorité les plus bas dans Julia en ce moment sont

1. Devoirs incluant += etc., := , => , et ~
2. L'opérateur ternaire ?
3. ||
4. &&

Je pense que cela a du sens (pas sûr de ~ , mais ce n'est pas la question). Les and et or logiques sont utiles à la fois comme partie droite des affectations et comme condition de ? . Si vous allez utiliser une affectation ou un opérateur ternaire comme argument pour and ou or , je pense que vous savez que vous faites quelque chose d'inhabituel et que les parenthèses sont de mise.

Au fait, je pense que beaucoup de gens s'attendraient à ce qu'un langage qui utilise and et or pour les opérations logiques utilise not pour la négation logique. Mais si nous avons de bonnes raisons de garder ! , ça peut aller. (Je suppose que ! n'est pas strictement une négation logique, du moins si #4892 est implémenté est fusionné.)

Je serais un peu triste à propos de not au lieu de ! , mais je vais faire n'importe quoi ici.

Je ne pense vraiment pas que not soit du tout analogue – and et or sont des opérateurs de flux de contrôle, pas des fonctions, alors que ! n'est qu'une fonction.

Je suis d'accord avec Stéphane. La seule chose que not vous apporte vraiment, c'est de ne pas avoir à utiliser autant de parenthèses. Je pense que c'est une question distincte.

Je parlais juste des attentes initiales des nouveaux utilisateurs. Mais je pense
il semble y avoir une bonne raison de pouvoir garder !

J'aimerais être contraire. Un certain nombre de langages utilisent && et ||, y compris tous ceux que j'ai utilisés avec une certaine régularité, et ceux-ci sont toujours en court-circuit. Avec et/ou je n'aurais aucune attente intuitive s'ils court-circuitent ou non. J'aime aussi comment && et || sont clairement séparés visuellement des noms et numéros des variables.

Le tableau sur http://en.wikipedia.org/wiki/Short-circuit_evaluation peut avoir une certaine pertinence pour cette discussion.

En tant que personne venant du monde Python, je suis surpris de me retrouver d'accord avec @GunnarFarneback. Dernièrement, j'ai découvert que les conditionnels anglais ( and , or , not ) m'amenaient souvent à écrire un code incorrect que je m'attendais naïvement à fonctionner (parce que cela a du sens dans anglais) et ensuite devoir me gratter la tête pendant quelques secondes pendant que je me convertis mentalement de l'anglais aux déclarations logiques avant de réaliser mon erreur. Cela dit, je ne suis pas particulièrement biaisé dans un sens ou dans l'autre; je mets juste mon 2¢.

Je suis aussi pour and et or

+1

+1
avoir les deux opérateurs
and et or avec une priorité faible
Je dirais que cond = f() && g() devrait s'écrire cond = (f() && g()) .
Je soutiens également l'utilisation de not avec une faible priorité au motif que ! , qui a une forte priorité dans tous les contextes que j'ai vus, nécessite if !(something and something) que je n'aime pas sur certains , niveau irrationnel et immuable. J'ai aussi l'impression que ! est parfois difficile à voir. J'ignore également l'origine de ! mais je pense qu'il a une place plus légitime en tant qu'opérateur factoriel sur les entiers - d'où une préférence pour la syntaxe ~ de matlab.

@johnmyleswhite ce problème sera-t-il clos ? Je pense que le navire a navigué sur celui-ci.

:(

court-circuit ce visage renfrogné

Je pense que nous devrions toujours considérer cela. Beaucoup de gens semblent ne pas aimer utiliser && et || comme nous les utilisons et préféreraient and et or . Il y a aussi la question de la préséance, ce qui rend && et || quelque peu gênants. Nous pourrions passer à un futur où && et || nécessitent que les deux opérandes soient booléens et que and et or fassent quoi && et || font actuellement mais avec une priorité inférieure afin que vous puissiez écrire x == nothing and x = 0 et autres. Soit cela, soit introduisez une syntaxe conditionnelle d'une ligne différente comme x = 0 if x == nothing .

La dernière syntaxe x = 0 if x == nothing a certains des problèmes IMO que la suggestion dans https://groups.google.com/forum/#!topic/julia -dev/cnmLcNg8h0Q fait.
Les deux options suivantes sont-elles si horribles que Julia a besoin de post-conditionnels ?

    if x == nothing ; x = 0 ; end

ou

   x == nothing && (x = 0)

Cela dit, tout comme cela ne me dérangerait pas de voir une construction repeat ; expr(s) ; until cond dans Julia (mais peut vivre sans), je ne vois rien de mal à avoir and et or ajouté à Julia.
Ils semblent mieux s'adapter à la syntaxe julia que d'utiliser les emprunts de C && et || .

Je pense que nous devrions toujours considérer cela.

+1

J'ai été surpris que l'affectation ait une priorité inférieure à || , alors je suis venu à la recherche d'une discussion précédente et j'ai trouvé ce problème. Ce n'est pas grave, mais ces parenthèses me semblent hors de propos. Il m'a fallu un certain temps (plusieurs secondes, je pense, et un test dans REPL) pour savoir quel emplacement d'affectation n'était pas valide. - Le message d'erreur indiquait la ligne après la fin de la définition de la fonction.

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

En revanche, les parenthèses dans cond = (f() && g()) me paraissent bien. Je pense que je les utiliserais de toute façon.

Pour ce que ça vaut, je préférerais aussi and et or .

+1 de moi aussi.

La réponse est presque unanimement positive en faveur de and etc. Je compte deux avis contre, un indifférent, un couple indéterminé et tous les autres (15 ou plus) en faveur.

Un argument contre (plus difficile à lire) que je pense est incorrect. L'argument est que foo and bar est plus difficile à lire que foo && bar à cause de 3 mots contre mot SYMBOLE mot. Cependant, tout le monde utilise la coloration syntaxique, et dans ce cas, c'est l'inverse qui se produit. and est coloré en tant que mot-clé, donc a<1 and b>3 colorera en fait en faveur de la séparation visuelle des sous-expressions gauche et droite, alors que a<1 && b>3 les trois opérateurs seront de la même couleur, indice potentiel opérateur-précédence-tête-grattage.

Un argument _pour_ qui n'a pas encore été présenté est qu'il existe une cohérence élégante pour les opérateurs booléens étant des mots, car le résultat de l'opération est soit true soit false , c'est-à-dire aussi un mot. Il est donc très facile pour un débutant de mémoriser & vs and pour le bitwise versus logique. Il est beaucoup plus difficile de mémoriser & vs && , car il s'agit d'une assignation arbitraire. Il est garanti que les débutants utiliseront & manière incorrecte, car & transmet le mot and en anglais. Cela peut provoquer des bogues de précédence (?).

Un autre argument possible _pour_ serait que le cerveau analyse naturellement {GROUPE DE SYMBOLES} mot {GROUPE DE SYMBOLES}.

Pourquoi ne pas simplement changer ? C'est toujours le meilleur moment pour le faire, ça ne sera jamais plus facile que maintenant. Il n'est pas vraiment difficile de corriger le code qui utilise actuellement &&.

Avoir and or not xor peut-être nand juste pour être complet ?? Cela ne me dérange pas l'idée de garder ! . Laissez le programmeur choisir quand utiliser lequel. Aucun problème avec cela! Cela dit, ! déjà une utilité dans les fonctions de style foo! , il y a donc un argument "minimiser la réutilisation des symboles".

@StefanKarpinski, il semble y avoir un consensus en faveur de 2013, je pourrais essayer de le mettre en œuvre, mais je crains que cela ne soit pris en compte, car ce problème n'a pas été clos, je suppose qu'il est toujours ouvert pour discussion? L'utilisation de ces mots au lieu de symboles ira bien avec isa étant également un opérateur infixe, comme avec true , false , end , etc. Il semble plus cohérent et lisible de cette façon.

+1

Je viens de passer à Julia depuis Python. Il semble que Julia risque d'être victime d'un débordement de symboles. Pour des raisons de code lisible par l'homme, je soutiens fortement and et or

La prise en charge du mot-clé not pourrait également améliorer la lisibilité du code.

Devrions-nous déprécier/interdire l'utilisation de and et or (et éventuellement not ) dans 0.7/1.0, respectivement, pour pouvoir les ajouter plus tard au cas où nous déciderions de vraiment comme eux ?

Je serais d'accord avec ça. Je parie que @JeffBezanson est contre, mais si nous refusons maintenant, nous pouvons toujours changer d'avis plus tard et l'autoriser, alors que nous ne pouvons pas aller dans l'autre sens. Il peut également être utile de pouvoir envoyer un simple message d'erreur "Utilisez && au lieu de and " aux utilisateurs qui essaient des opérateurs de style Python.

Je pense que ce serait génial !

Réouverture et ajout de jalon pour s'assurer que nous n'oublions pas.

Je ne comprends pas l'intention du jalon, nous allons ajouter and et or ? nous le reconsidérons? vous cherchez une autre utilisation de cela? Ou vous voulez dire que vous allez ajouter des dépréciations comme des avertissements, afin que les personnes venant de Python sachent utiliser && au lieu de and ?

J'avais https://github.com/JuliaLang/julia/pull/19788 dans lequel ils étaient des alias, mais je peux changer cela pour les remplacer.

Le jalon devrait signifier : prendre une décision. Ou, si nous ne pouvons pas prendre une décision à temps, désapprouvez toute utilisation de and et or afin que nous puissions reporter la décision sans risquer de casser le code de quiconque plus tard.

Je comprends qu'étant donné l'aspiration à geler le code dans quelques semaines, il est peut-être trop tard pour rouvrir cette boîte de vers maintenant (et j'apprécie l'idée d'ajouter des amortissements pour laisser la porte ouverte pour l'avenir), mais une pensée:

Lorsque cela a été discuté pour la première fois (2013), je pense que la communauté Julia était principalement composée de développeurs - des personnes ayant une solide expérience en informatique qui étaient plus qu'habitués à utiliser && et || . Je _suspect_ que les personnes qui pourraient apprécier le plus and et or sont des utilisateurs appliqués qui ne sont pas aussi à l'aise avec les salades ascii et qui n'ont pas encore passé suffisamment de temps dans des langues plus anciennes pour s'habituer entièrement à && et || . Il pourrait être intéressant de voir ce que les gens pensent de cela si nous interrogeons les utilisateurs actuels de Julia (surtout si nous l'avons évoqué dans un discours où plus de non-développeurs sont susceptibles de le voir).

Ce qui a été proposé est de réserver la syntaxe and , or et not . Si nous faisons cela, nous pouvons les ajouter en tant qu'opérateurs à tout moment dans la chronologie 1.x. Aucune autre discussion n'est nécessaire pour l'instant.

Je serais d'accord pour les analyser comme des erreurs de syntaxe permanentes, comme nous le faisons avec ** . Mais je suis toujours très, très contre leur donner une quelconque signification autrement.

Je trouve aussi dommage qu'on déterre d'anciens problèmes pour lesquels une décision a déjà été prise, surtout si proche de 1.0.

Pour être clair : cela se fait si quelqu'un le fait.

Merci pour la clarification! :RÉ

Il me semble très idiot de prendre la peine de les analyser et d'interdire d'autres utilisations, et d'en faire néanmoins une erreur de syntaxe. Je pense que la plupart des gens préféreraient ne pas avoir une situation où and et or sont des mots réservés (c'est-à-dire non utilisables dans des contextes comme <strong i="7">@stackeval</strong> 1 0 and 1 or ) mais ne font rien d'utile. Je suggérerais soit qu'ils ne soient pas analysés du tout, soit qu'ils soient analysés comme des alias (ce qui n'est pas inhabituel, car C et Ruby le font).

Nous avons déjà décidé de ne pas les analyser comme des alias, c'est pourquoi le PR a été fermé. Donc +1 pour ne pas les analyser du tout.

Au risque de ressasser cette discussion qui a eu lieu jusqu'à la nausée, je note qu'en ce qui concerne C et Ruby, utiliser and et or en C est très rare dans mon expérience, et le plus les guides de style Ruby courants nécessitent && et || au lieu de and et or .

IMHO: il semble que les débats d'origine aient été plutôt divisés, et l'ajout de cette protection laisse simplement de la place à la communauté pour la revoir à l'avenir si elle le souhaite.

Je ne sais pas pourquoi cela a été rouvert.

Un dialecte Julia avec des fonctionnalités syntaxiques comme celui-ci pourrait être réalisé facilement en utilisant JuliaParser.jl, une fois les API internes et de méta-programmation stabilisées, impatient ! :le sourire:

Pour ceux qui abordent ce problème sans avoir suivi ce qui s'est passé : bien que l'idée d'utiliser and et or recueilli un bon soutien *), le premier PR à aborder le problème - #19788 - a principalement conduit à une discussion non concluante pour savoir si and et or devraient être des remplacements directs pour && et || ou devraient avoir une sémantique légèrement différente, par exemple en ce qui concerne à la préséance, mais simplement en faire des alias était considéré comme indésirable. Le PR #24965 aurait réservé les mots-clés (avec not ), pour permettre de leur donner un sens pendant le cycle 1.x. Cependant, la discussion lors d'un appel de triage a entraîné une désapprobation, de sorte que le premier point auquel cela pourrait être reconsidéré est pour 2.0. (Et il faudrait probablement présenter des arguments vraiment convaincants pour que le changement se produise alors.)

*) Il semble que le changement proposé soit moins populaire auprès des développeurs plus influents/"core", donc le simple fait de regarder le nombre de peut être trompeur, cependant.

J'espère que je n'ai pas trop simplifié et que j'ai bien fait les choses. Désolé si je ne l'ai pas fait.

donc le premier point auquel cela pourrait être reconsidéré est pour 2.0. (Et il faudrait probablement présenter des arguments vraiment convaincants pour que le changement se produise alors.)

Je ne vois pas pourquoi cela arriverait si nous avons décidé plusieurs fois de ne pas le faire. J'espère que nous pourrons éviter de creuser à nouveau ce problème pour chaque version majeure.

Si Julia reste assez longtemps pour rivaliser avec Python, je peux garantir que cela se produira de plus en plus. De nombreux utilisateurs de Python ne souhaitent pas revenir à la syntaxe C. C'est l'une des nombreuses raisons pour lesquelles Python est si populaire : facile à apprendre, addictif à utiliser, vous ne voudrez pas revenir à l'ancienne façon de faire les choses.

Les concepteurs de nouveaux langages prétendent souvent qu'ils veulent une syntaxe conviviale, mais ils ont tendance à se perdre dans des fonctionnalités sophistiquées que seul un petit sous-ensemble d'utilisateurs voudra ou utilisera, tout en négligeant les ajustements simples qui pourraient favoriser l'adoption.

Exemple concret : les opérateurs Unicode bizarres sont pris en charge , mais pas le langage naturel and et or .

R utilise également && et || et 1-indexation. Ce n'est pas seulement des langages plus anciens (ou de niveau inférieur comme C). Je ne sais pas quoi utiliser mais ce n'est pas plus difficile : j'ai enseigné à la fois R et Python à des débutants complets (aucune différence de programmation) et ce n'est pas ce avec quoi ils ont lutté. Habituellement, les concepts sous-jacents étaient plus importants et prenaient plus de temps à apprendre que les symboles ou les mots utilisés pour écrire le code. La syntaxe "conviviale" et "intuitive" pour vous en tant qu'utilisateur R, Python, C, etc. sera différente simplement à cause de ce que vous connaissez déjà. Ce n'est pas le cas pour les débutants absolus dont nous devrions être plus concernés ici car je pense que ceux qui ont de l'expérience en programmation dans d'autres langages ont l'expérience et l'expertise pour gérer les différentes conventions dans un nouveau langage.

La seule raison qui semble avoir été évoquée ici est que Python utilise and et or et des gens comme ça. Est-ce que cela vaut la peine de changer? Julia n'est pas Python et ne devrait pas essayer de l'être. Nous avons déjà Python. Pour donner à quiconque la motivation de passer à une nouvelle langue, cela devrait être différent. Les nouveaux utilisateurs de Julia peuvent ne pas être des programmeurs Python, ils peuvent avoir de l'expérience avec un langage différent (ou pas du tout s'il devient suffisamment populaire).

Je reconnais qu'il s'agit probablement d'un problème mort, mais en réponse à @TomKellyGenetics , je suggérerais que, à mon && opérateurs and , or ) plus familiers et lisibles qu'ils soient Python utilisateurs ou non.

R utilise également && et || et 1-indexation. Ce ne sont pas seulement des langages plus anciens (ou de niveau inférieur) comme C).

Je faisais référence aux langages de type C, c'est-à-dire aux langages qui empruntent fortement la syntaxe du C, généralement avec l'argument auto-réalisateur de « c'est la syntaxe que tous les autres langages utilisent ». La syntaxe R est plutôt de type C, bien qu'elle diverge ici et là. Julia ressemble plus à Fortran qu'à C, bien qu'il y ait un certain chevauchement.

J'ai enseigné à la fois R et Python aux débutants complets (aucune différence de programmation) et ce n'est pas ce avec quoi ils ont lutté.

Les étudiants IME novices en programmation luttent avec la syntaxe en plus de tout le reste, c'est la mort par mille coupures. La programmation est étrangère, et choisir des symboles abstraits plutôt que du langage naturel la rend encore plus étrangère et facile à oublier. J'entends souvent des débutants dans des langages de type C demander des choses comme : « Comment écrivez-vous 'ou' encore ? »
Mais le langage naturel en programmation n'est pas seulement un problème pour les débutants. Même les programmeurs expérimentés sont plus susceptibles de rater un ! qu'un not , et beaucoup trouvent qu'il est plus facile de lire et de taper rapidement or et and sur || et && .

Julia n'est pas Python et ne devrait pas essayer de l'être. Nous avons déjà Python. Pour donner à quiconque la motivation de passer à une nouvelle langue, cela devrait être différent.

Julia n'est pas non plus C ou Fortran. La grande majorité des langages populaires ressemblent au C, donc se démarquer signifie généralement faire quelque chose de différent du C. faire mieux. Utiliser un langage plus naturel est une façon. Il convient de noter que Fortran 77 et versions ultérieures utilisent .not. , .and. et .or. à bon escient. En ce sens, je veux en fait que Julia ressemble plus à Fortran, moins à C !

Ce problème a été résolu; and et or sont autorisés comme identifiants et nous continuerons à utiliser && et || pour le flux de contrôle. Je ne sais pas pourquoi cela est encore en discussion.

Il existe une tendance à surestimer l'importance des problèmes de syntaxe superficielle, car ils sont très visibles, faciles à discuter et leurs implications sont généralement claires. Dans un autre domaine, un langage est considéré comme inutilisable à moins que les blocs de code ne soient entourés d'accolades, auquel cas julia et python sont hors de portée.

Je pense qu'il est discutable si a and b est en effet plus lisible que a && b . && se démarque davantage. Le fait que || et && soient de la même longueur peut également conduire à un formatage plus agréable. L'une des raisons pour lesquelles les symboles d'opérateur comme a = b et a + b fonctionnent si bien est qu'ils ajoutent une structure visuelle sur quelque chose comme set a to b . a[i] ou element i of a ?

vous ne voudrez pas revenir à l'ancienne façon de faire les choses.

Pour moi, l'ancienne façon de faire les choses est la gestion manuelle de la mémoire et la faible prise en charge du polymorphisme, pas l'orthographe de && .

Julia a quelques expressions en langage naturel, telles que for a in [1, 2, 3] . Cela se lit mieux et est plus intuitif que for a = [1, 2, 3] , que Julia prend également en charge. Je ne suggérerais certainement pas que nous fournissions des alternatives en langage naturel pour tous les opérateurs symboliques, seulement les quelques-uns qui rendent Julia plus intuitive et lisible.

FWIW, j'ai voté pour adopter les deux ensembles d'opérateurs, pour faciliter l'adoption et donner aux utilisateurs des choix de style. Dans les projets C++ où les gens utilisent les deux, cela ne m'a jamais dérangé. Je n'y vois aucun mal, seulement des avantages.

Dans l'ensemble, j'aime la direction prise par la syntaxe de Julia. Un bon équilibre entre le langage naturel et les symboles, prouvant qu'un langage numérique peut exceller dans la programmation à usage général. J'ai hâte de voir comment il grandit et se développe. C'est ma façon de dire que l'ajout des opérateurs de langage naturel est techniquement rétrocompatible. :sourire:

Je vais essayer or réserver and et not pour une éventuelle utilisation future, et d'émettre un avertissement / suggestion d'utiliser les symboles correspondants. Dois-je le faire dans Julia 0.7, 1.0 ou les deux ?

24965 ?

Ah, j'ai raté ça, merci ! Je suppose que ne pas réserver de mots-clés n'empêche pas de prendre en charge ces mots-clés à l'avenir.

Désolé, lisez toutes les discussions, mais je n'ai toujours pas compris, comment puis-je utiliser and , or dans Julia maintenant ?

Tu ne peux pas