+1
私は本当にこれが起こるのを見たいです。
インデックス作成に使用されるendように読みやすくなります。

+1
2013年12月27日午後1時6分、「GaborOszlanyi」 [email protected]は次のように書いています。

+1
私は本当にこれが起こるのを見たいです。
インデックス作成に使用されるendのように読みやすくなります。

—
このメールに直接返信するか、Gi tHubhttps：//github.com/JuliaLang/julia/issues/5238#issuecomment-31280112で表示してください
。

私もこの提案が好きです。

私はこれが得ているサポートのうねりに少し驚いています。 スペルアウトされた演算子は制御フローに対してはるかに直感的であると常に感じていましたが、その感覚が広まっていることに気づきませんでした。

あなたがこの提案をしたとき、私はファンではありませんでしたが、もう少し考えた後、それは私にとっても非常に理にかなっていると言わなければなりません。 これらは、テキストではなく記号を使用する他のすべての演算子とは対照的に、実際には制御フロー演算子です。 これにより、 &および|との混同を減らすことができます。

andとorを提供する言語（Perl、Ruby、Lua-私がチェックした言語）もnotを提供することに気づきました（Luaは提供していません） ! ）。 私の最初の反応は、 !と重複しているので、気に入らないということです。 しかし、おそらくこれらの言語がそうすることを選んだ強い理由があります。

私は個人的にnot大好きですが、 not切り替えることで、 andとor使用することによるあいまいさの軽減のようなものはないと思います。

notも短絡/制御フロー操作ではなく、結合性に関しては常にそれを読み取る方法に苦労しています。 Pyhtonで私が気に入っているのはif not ...だけですが、それは制御フロー操作として読んだからです。

+1

短絡としてXORを追加することもできますか？
そして、反転バージョン（XNOR、NAND、NOR）の短絡バージョン？

XORは決して短絡可能ではありません。 他のものは、 !加えて、 andおよびor演算子を使用して簡単に記述できます。

+1
Rubyでは、&&と 'および'（http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/）について常に混乱が生じていることを指摘しておきます。 Rubyが両方の演算子のセットを持つために使用する合理性を念頭に置き、混乱させる価値があるかどうか、または&&を完全に削除して 'と'を優先するかどうかを決定するとよいでしょう。

andとorは、PerlやRubyのように優先順位を非常に低くして、次のようなものを記述できるようにしたいと思います。

k <= n and k *= 2

ブール結果を何かに割り当てたい場合があります。

cond = f() && g()

それと矛盾しているようです。

そういうわけで、RubyとPerlの両方に優先順位の異なる演算子のセットがあります。 それを支持するのではなく、ただ言っているだけです。 その使用法が実際にどれほど一般的であるかはわかりませんが、コードを調べると、多くのk <= n && (k *= 2)種類のものが明らかになります。

まず、私はandとorます。
現在、ジュリアで最も低い4つの優先グループは

1. +=など、 := 、 => 、および~を含む割り当て
2. 三項演算子?
3. ||
4. &&

これは理にかなっていると思います（ ~についてはわかりませんが、それは重要ではありません）。 論理andとorは、割り当ての右側と?条件の両方として役立ちます。 andまたはor引数として代入演算子または三項演算子を使用する場合は、何か変わったことをしていることと、括弧が正しいことを知っていると思います。

ところで、多くの人は、論理演算にandとorを使用する言語が、論理否定にnotを使用することを期待していると思います。 しかし、 !を保持する正当な理由がある場合は、それで問題ない可能性があります。 （少なくとも＃4892が実装されている場合、 !は厳密には単なる論理否定ではないと思います。）

not代わりに! notについては少し悲しいでしょうが、ここでは何でもやります。

notがまったく類似しているとは思いません。 andとorは制御フロー演算子であり、関数ではありませんが、 !は単なる関数です。

ステファンに同意します。 not実際に得られる唯一のことは、それほど多くの括弧を使用する必要がないことです。 それは別の問題だと思います。

私はちょうど新しいユーザーの最初の期待について話していました。 しかし、私は思います
維持できるのには確かな理由があるようです！

反対になりたいです。 かなりの数の言語が&&と||を使用しています。これには、私が定期的に使用しているすべての言語が含まれ、それらは常に短絡しています。 と/または私はそれらが短絡するかどうかにかかわらず直感的な期待はありません。 &&と||も好きです変数の名前や番号から視覚的に明確に分離されています。

http://en.wikipedia.org/wiki/Short-circuit_evaluationの表は、この議論にある程度関連している可能性があります。

Pythonの世界から来た人として、@ GunnarFarnebackに同意していることに驚いています。 最近、英語の条件（ and 、 or 、 not ）を使用すると、単純に機能すると予想される誤ったコードを記述してしまうことがよくあります（英語）そして、エラーに気付く前に、英語から論理的なステートメントに精神的に変換している間、数秒間頭を掻く必要があります。 そうは言っても、私はどちらの方向にも特に偏っていません。 私の2¢を入れるだけです。

私もandとor求めています

+1

+1
両方の演算子があります
andとor優先順位が弱い
cond = f() && g()はcond = (f() && g())と書くべきだと私は主張します。
私はまた、 notの使用をサポートしますが、これは、私が見たすべてのコンテキストで強い優先順位を持つ! 、いくつかの深いところで嫌いなif !(something and something)を必要とするという理由で弱い優先順位です、不合理で、変更できないレベル。 また、 !が見づらい場合もあります。 私は彼の!起源にも無知ですが、整数の階乗演算子としてより正当な場所があると感じています。したがって、matlabの~構文が優先されます。

@johnmyleswhiteこの問題は解決されましたか？ 船はこれで出航したと思います。

:(

顔をしかめる短絡

私たちはまだこれを考慮すべきだと思います。 多くの人は、 &&と||を私たちが使用している方法で使用することを嫌い、 andとorを好むようです。 優先順位の問題もあり、 &&と||やや厄介になります。 &&と||両方のオペランドがブール値である必要があり、 andとorが&&と||を実行する未来に移行する可能性があります。 x == nothing and x = 0などを記述できます。 それか、 x = 0 if x == nothingような別の1行の条件構文を導入します。

最後の構文x = 0 if x == nothingは、 https： //groups.google.com/forum/#！topic / julia-dev / cnmLcNg8h0Qの提案にあるIMOの問題がいくつかあり
次の2つのオプションは、ジュリアが事後条件文を必要とするほどひどいですか？

    if x == nothing ; x = 0 ; end

また

   x == nothing && (x = 0)

そうは言っても、Juliaでrepeat ; expr(s) ; until cond構造を見ても構わないのと同じように（ただし、それがなくても生きることができます）、 andとorを持っていても問題はありません。ジュリアに
これらは、C &&および||から借用したものを使用するよりも、julia構文にうまく適合しているようです。

私たちはまだこれを考慮すべきだと思います。

+1

割り当ての優先順位が||よりも低いことに驚いたので、前のディスカッションを探して、この問題を見つけました。 それは大したことではありませんが、それらの括弧は私には場違いに見えます。 どの割り当て場所が無効であるかを見つけるのにしばらく時間がかかりました（数秒、REPLでのテスト）。 -エラーメッセージは、関数定義の終わりを過ぎた行を示していました。

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

対照的に、 cond = (f() && g())の括弧は私には大丈夫に見えます。 とにかく使うと思います。

その価値については、 andとorます。

私からも+1。

回答はほぼ満場一致でandなどに賛成です。私は2つの意見を数えます。1つは無関心、2つは不特定、そして他のすべての人（15人以上）は賛成です。

（読みにくい）反対の1つの議論は間違っていると思います。 議論は、 foo and barは、単語SYMBOL単語に対して3単語であるため、 foo && barよりも読みにくいということです。 ただし、誰もが構文の強調表示を使用しており、この場合は逆になります。 andはキーワードとして色付けされているため、 a<1 and b>3は実際には左右の部分式を視覚的に分割するために色付けされますが、 a<1 && b>3は3つの演算子すべてが同じ色になります。潜在的なオペレーターの手がかり-優先順位-ヘッドスクラッチ。

まだ提示されていない引数_for_は、演算の結果がtrueまたはfalseいずれか、つまり単語であるため、ブール演算子が単語であることにエレガントな一貫性があるということです。 したがって、初心者がビット単位と論理演算で&とandを覚えるのは非常に簡単です。 &と&&は任意の割り当てに見えるため、覚えるのははるかに困難です。 & andは英語で&誤って使用します。 これにより、優先バグ（？）が発生する可能性があります。

もう1つの考えられる議論は、脳が{BUNCH OFSYMBOLS}単語{BUNCHOFSYMBOLS}を自然に解析するというものです。

切り替えてみませんか？ 今が常にそれを行うのに最適な時期であり、今よりも簡単になることは決してありません。 現在&&を使用しているコードを修正することはそれほど難しくありません。

and or not xor多分nandは完全を期すためですか？ !を維持するという考えは気にしません。 いつどちらを使用するかをプログラマーに選択させます。 それは何も悪いことではありません！ そうは言っても、 !すでにfoo!スタイルの関数で使用されているため、「シンボルの再利用を最小限に抑える」という議論があります。

@StefanKarpinski 2013年からの賛成のコンセンサスがあるようです。これを実装しようと試みることはできますが、この問題はまだ解決されていないため、これが考慮されるかどうか心配です。議論？ 記号の代わりにこの単語を使用すると、 true 、 false 、 endなどと同じように、 isaも中置演算子になります。この方法でより一貫性があり、読みやすくなります。

+1

PythonからJuliaに移行するだけです。 ジュリアはシンボルオーバーフローに陥る危険があるようです。 人間が読めるコードのために、私はandとorを強くサポートします

notキーワードをサポートすると、コードの可読性も向上する可能性があります。

0.7 /1.0でそれぞれandとor （および場合によってはnot ）の使用を非推奨/禁止して、後でこれらを追加できるようにする必要があります。本当に彼らが好きですか？

私はそれで落ち込んでいるでしょう。 @JeffBezansonは反対だと&&代わりにand &&使用する」というエラーメッセージを表示できると便利な場合もあります。

それは素晴らしいことだと思います！

マイルストーンを再開して追加し、忘れないようにします。

マイルストーンの意図がわかりません。 andとorを追加しますか？ 私たちはそれを再考していますか？ これの別の使用法をお探しですか？ または、警告などの非推奨を追加する予定なので、Pythonから来た人は、 and代わりに&&を使用することを知っていますか？

https://github.com/JuliaLang/julia/pull/19788にエイリアスがありましたが、変更して置き換えることができます。

マイルストーンは次のことを意味する必要があります。決定を下す。 または、時間内に決定に達することができない場合は、 andとor使用を非推奨にして、後で誰かのコードを壊すリスクを冒さずに決定を延期できるようにします。

数週間でコードを凍結したいという願望を考えると、このワームの缶を今すぐ再開するのは遅いかもしれないことを理解しています（そして、将来のためにドアを開いたままにするために減価償却を追加するというアイデアに感謝します）が、1つの考え：

これが最初に議論されたとき（2013）、Juliaコミュニティは主に開発者だったと思います-CSのバックグラウンドが強く、 &&と||使用に慣れている人々です。 andとor最も高く評価する可能性のある人々は、ASCIIサラダに慣れておらず、完全に慣れるために古い言語で十分な時間を費やしていない応用ユーザーであると私は_疑っています_ &&および|| 。 現在のJuliaユーザーをポーリングした場合（特に、より多くの非開発者がそれを見る可能性が高い談話でそれを取り上げた場合）、人々がこれについてどのように感じたかを見るのは興味深いかもしれません。

提案されているのは、 and 、 or 、およびnot構文を予約することです。 そうすれば、1.xタイムラインの任意の時点でこれらを演算子として追加できます。 今のところ、これ以上の議論は必要ありません。

**場合と同様に、これらを永続的な構文エラーとして解析しても問題ありません。 しかし、私はまだ彼らに他の方法で何らかの意味を与えることに非常に反対しています。

また、特に1.0に非常に近い、すでに決定が下されている古い問題を掘り下げているのも残念です。

明確にするために：これは誰かがそれをした場合に行われます。

説明してくれてありがとう！ ：NS

それらを解析して他の使用を禁止することをわざわざすることは私には非常にばかげているように思えますが、それでも構文エラーになります。 ほとんどの人は、 andとorが予約語である（つまり、 <strong i="7">@stackeval</strong> 1 0 and 1 orようなコンテキストでは使用できない）にもかかわらず、何も役に立たないという状況を望んでいないと思います。 それらをまったく解析しないか、エイリアスとして解析することをお勧めします（CとRubyが行うように、これは珍しいことではありません）。

それらをエイリアスとして解析しないことをすでに決定しているため、PRは終了しました。 したがって、それらをまったく解析しない場合は+1です。

ひどい目に遭ったこの議論を再ハッシュするリスクを冒して、CとRubyに関して、Cでandとorすることは私の経験では非常にまれであり、ほとんどの場合一般的なRubyのスタイルガイドが必要です&&と||の代わりにandとor 。

IMHO：当初の議論はかなり分かれていたようで、この保護を追加することで、コミュニティが将来希望するように再検討するためのスペースが残るだけです。

なぜ再開されたのかわかりません。

このような構文機能を備えたJulia方言は、JuliaParser.jlを使用して簡単に実行できます。内部APIとメタプログラミングAPIが安定すると、それを待つことはできません。 ：笑顔：

起こったことに従わずにこの問題に来た人のために： andとorを使用するというアイデアはかなりの量のサポートを集めましたが*）、問題に取り組む最初のPR-＃19788 -主に、 andとorを&&と||直接の代替品にするべきか、それともわずかに異なるセマンティクスを持つべきかなど、決定的な議論につながりました。優先しますが、それらをエイリアスにするだけでは望ましくないと見なされました。 PR＃24965は、1.xサイクル中にキーワードに意味を与えることができるように、キーワードを（ notとともに）予約していました。 ただし、トリアージコール中の話し合いは不承認となったため、これを再検討できる最も早い時点は2.0です。 （そして、変更が発生するためには、おそらく本当に説得力のある主張をする必要があるでしょう。）

*）提案された変更は、より影響力のある/「コア」開発者にはあまり人気がないように思われるため、👍の数を見るだけでは誤解を招く可能性があります。

私は過度に単純化せず、物事をきちんと正しくしたことを願っています。 私がしなかった場合はお詫び申し上げます。

したがって、これを再検討できる最も早い時点は2.0です。 （そして、変更が発生するためには、おそらく本当に説得力のある主張をする必要があるでしょう。）

今、何度もやらないと決めたら、なぜそうなるのかわかりません。 メジャーリリースごとにこの問題を掘り下げることを避けられることを願っています。

JuliaがPythonと競争するのに十分な長さで立ち往生していれば、これがますます増えることを保証できます。 多くのPythonユーザーは、C構文に戻りたくありません。 これは、Pythonが非常に人気がある多くの理由の1つです。習得が容易で、使い勝手がよく、古いやり方に戻りたくないでしょう。

新しい言語設計者は、ユーザーフレンドリーな構文が必要だと主張することがよくありますが、採用を促進する可能性のある単純な調整を見落としながら、ユーザーのごく一部だけが必要または使用するであろう派手な機能に迷う傾向があります。

適切な例：andおよびorはサポートされていません。

Rは&&と||と1-インデックスも使用します。 それは古いだけではありません（またはCのような低レベル言語）。 どちらを使用するかは無関心ですが、それほど難しくはありません。RとPythonの両方に初心者を完了するように教えました（プログラミングの違いはありません）。これは彼らが苦労したことではありません。 通常、基礎となる概念は、コードの記述に使用される記号や単語よりも重要であり、学習に時間がかかりました。 R、Python、Cなどのユーザーとしての「ユーザーフレンドリー」と「直感的」な構文は、すでに慣れ親しんでいるという理由だけで異なります。 他の言語でプログラミングの経験がある人は、新しい言語でさまざまな規則を処理する経験と専門知識を持っていると思うので、ここでもっと気にする必要があるまったくの初心者には当てはまりません。

ここで提起されたと思われる唯一の理由は、Pythonがandとorなどを使用していることです。 それは切り替えるのに苦労する価値がありますか？ ジュリアはPythonではないので、そうしようとすべきではありません。 私たちはすでにPythonを持っています。 誰かに新しい言語に切り替える動機を与えるには、それは違うはずです。 Juliaの新規ユーザーは、Pythonプログラマーではない可能性があり、異なる言語の経験がある可能性があります（または、十分に普及した場合はまったく経験がない可能性があります）。

これはおそらく死んだ問題だと思いますが、 なされ、特にユーザーフレンドリーではないと主張することをお勧めします...そして初心者には同意しますが、 &&演算子は「彼らが苦労したものではありません」、私が教えたほとんどの学生は、Pythonであるかどうかにかかわらず、英語の演算子（ and 、 or ）をよりよく知っていて読みやすいと思いますユーザーかどうか。

Rは&&と||も使用しますおよび1-インデックス作成。 C）のような古い（または低レベルの）言語だけではありません。

私はCに似た言語、つまりCから構文を多用する言語について言及していましたが、通常は「他のすべての言語が使用する構文です」という自己達成的引数があります。 R構文はCに似ていますが、あちこちで分岐しています。 いくつかの重複はありますが、JuliaはCよりもFortranに似ています。

私はRとPythonの両方に初心者を完成させるように教えました（プログラミングの違いはありません）が、これは彼らが苦労したことではありません。

プログラミングに不慣れなIMEの学生は、何よりも構文に苦労しています。それは千の削減による死です。 プログラミングは異質であり、自然言語よりも抽象的な記号を選択すると、それはさらに異質で忘れやすくなります。 Cのような言語の初心者が、「どうやって 『または』をもう一度書くのですか？」などと尋ねるのをよく耳にします。
しかし、プログラミングにおける自然言語は、初心者だけの問題ではありません。 でも、経験豊富なプログラマは欠場する可能性が高くなります!以上notそれはスピードに読み、入力し簡単に、そして多くのfind orとand以上||および&& 。

ジュリアはPythonではないので、そうしようとすべきではありません。 私たちはすでにPythonを持っています。 誰かに新しい言語に切り替える動機を与えるには、それは違うはずです。

JuliaはCでもFortranでもありません。 人気のある言語の大部分はCに似ているので、目立つということは通常Cとは違うことをすることを意味します。私は実際にはFortran、Cとその子孫が好きで、常にそれらを使用していますが、場所によっては不十分であり、うまくやる。 より自然な言語を使用することは1つの方法です。 Fortran 77以降では、 .not. 、 .and. 、および.or.を効果的に使用していることに注意してください。 この意味で、私は実際にJuliaをFortranに似たものにし、Cに似たものにしたくないのです。

この問題は解決されました。 andとorは識別子として許可されており、制御フローには引き続き&&と||を使用します。 なぜこれがまだ議論されているのかわかりません。

表面的な構文の問題は非常に目立ち、議論しやすく、その影響は通常明らかであるため、表面的な構文の問題の重要性を過大評価する傾向があります。 別の分野では、コードブロックが中括弧で囲まれていない限り、言語は使用できないと見なされます。中括弧の場合、juliaとpythonの両方が見劣りします。

a and bが実際にa && bよりも読みやすいかどうかa and b議論の余地があると思います。 &&はもっと際立っています。 ||と&&が同じ長さであるという事実も、より良いフォーマットにつながる可能性があります。 a = bやa + bような演算子記号がうまく機能する理由の1つは、 set a to bようなものの上に視覚的な構造を追加することです。 a[i]またはelement i of a ？

古いやり方に戻りたくないでしょう。

私にとって、物事を行う古い方法は、手動のメモリ管理とポリモーフィズムの弱いサポートであり、 &&スペルではありません。

Juliaには、 for a in [1, 2, 3]などの自然言語表現がいくつかあります。 これは、Juliaもサポートしているfor a = [1, 2, 3]よりも読みやすく、直感的です。 私は確かに、すべての記号演算子に自然言語の代替を提供することを提案しません。ジュリアをより直感的で読みやすくする少数の演算子だけです。

FWIW、私は、採用を容易にし、ユーザーにスタイルの選択肢を与えるために、両方の演算子のセットを採用することに投票しました。 人々が両方を使用するC ++プロジェクトでは、それは私を悩ませたことはありません。 害はなく、利益だけがわかります。

全体的に、私はジュリアの構文が進んだ方向が大好きです。 自然言語と記号の優れたバランスにより、数値言語が汎用プログラミングに優れていることが証明されます。 それがどのように成長し、発展するかを見るのが待ちきれません。 これは、自然言語演算子の追加は技術的に下位互換性があるという私の言い方です。 ：ニヤリ：

or 、 and 、 notを将来の使用に備えて予約し、対応する記号を使用するように警告/提案を発行します。 Julia 0.7、1.0、またはその両方でこれを行う必要がありますか？

24965？

ああ、それを逃した、ありがとう！ キーワードを予約しなくても、将来これらのキーワードをサポートできなくなるわけではないと思います。

申し訳ありませんが、すべてのディスカッションを読みましたが、それでも理解できませんorた。ジュリアでand 、 orを使用するにはどうすればよいですか？

あなたはできません