+1
Мне бы очень хотелось, чтобы это произошло.
Более читабельный, например end используемый для индексации.

+1
27 декабря 2013 г. в 13:06 "GaborOszlanyi" [email protected] написал:

+1
Мне бы очень хотелось, чтобы это произошло.
Более читабельный, как конец, используемый для индексации.

-
Ответьте на это письмо напрямую или просмотрите его на 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 существует постоянная путаница с && vs 'и' (http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/), поэтому Было бы хорошо, если бы мы имели в виду рациональность, которую использует Ruby, чтобы иметь оба набора операторов, и решить, стоит ли путаница или нужно ли полностью удалить && в пользу 'and'.

Я бы предпочел, чтобы and и or имели сверхнизкий приоритет, как в Perl и Ruby, чтобы вы могли писать такие вещи, как

k <= n and k *= 2

Иногда вы хотите присвоить логический результат чему-либо:

cond = f() && g()

Что, кажется, противоречит этому.

Что ж, именно поэтому Ruby и Perl имеют оба набора операторов с разным приоритетом. Не пропагандируя это, а просто говорю. Я не уверен, насколько распространено такое использование на самом деле, в то время как поиск в нашем коде показывает много чего типа k <= n && (k *= 2) .

Во-первых, я тоже за and и or .
Я вижу, что четыре младшие группы приоритета в Джулии прямо сейчас

1. Назначения, включая += и т. Д., := , => и ~
2. Тернарный оператор ?
3. ||
4. &&

Я думаю, что это имеет смысл (не уверен насчет ~ , но это не относится к делу). Логические and и or полезны как в качестве правой части присваивания, так и в качестве условия ? . Если вы собираетесь использовать либо присваивание, либо тернарный оператор в качестве аргумента для and или or , я думаю, вы знаете, что делаете что-то необычное и круглые скобки в порядке.

Кстати, я думаю, что многие люди ожидали бы, что язык, который использует and и or для логических операций, будет использовать not для логического отрицания. Но если у нас есть веская причина оставить ! , это может быть нормально. (Я предполагаю, что ! - это не строго логическое отрицание, по крайней мере, если реализовано # 4892, объединено.)

Мне было бы немного грустно из-за not вместо ! , но я выберу все, что здесь.

Я действительно не думаю, что not вообще аналогичен - and и or - это операторы потока управления, а не функции, тогда как ! - это просто функция.

Я согласен со Стефаном. Единственное, что действительно дает вам not , - это отсутствие необходимости использовать столько скобок. Думаю, это отдельная тема.

Я просто говорил о первоначальных ожиданиях новых пользователей. Но я думаю
кажется, есть веская причина, чтобы можно было сохранить!

Я бы хотел наоборот. Довольно много языков используют && и ||, включая все те, которые я использовал с какой-либо регулярностью, и это всегда короткое замыкание. С и / или у меня не было бы интуитивного ожидания, короткое замыкание они или нет. Мне также нравится, как && и || четко визуально отделены от имен и номеров переменных.

Таблица на http://en.wikipedia.org/wiki/Short-circuit_evaluation может иметь некоторое отношение к этому обсуждению.

Как человек из мира Python, я с удивлением обнаружил, что согласен с @GunnarFarneback. В последнее время я обнаружил, что английские условные выражения ( and , or , not ) часто приводят к тому, что я пишу неправильный код, который я наивно ожидал, что он будет работать (потому что это имеет смысл в english), а затем мне пришлось почесать голову в течение нескольких секунд, пока я мысленно переводил с английского на логические утверждения, прежде чем осознал свою ошибку. Тем не менее, я не особенно предвзято ни в одном из направлений; просто положил в мои 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 .

Последний синтаксис x = 0 if x == nothing имеет некоторые проблемы, IMO, которые предлагает предложение в https://groups.google.com/forum/#!topic/julia -dev / cnmLcNg8h0Q.
Неужели два следующих варианта настолько ужасны, что Джулии нужны постусловия?

    if x == nothing ; x = 0 ; end

или

   x == nothing && (x = 0)

Тем не менее, точно так же, как я был бы не против увидеть конструкцию repeat ; expr(s) ; until cond в Джулии (но могу жить без нее), я не вижу ничего плохого в наличии and и or добавил к Юлии.
Кажется, они лучше подходят для синтаксиса julia, чем для использования заимствованных из C && и || .

Думаю, нам еще стоит подумать над этим.

+1

Я был удивлен тем, что присвоение имеет более низкий приоритет, чем || , поэтому я поискал предыдущее обсуждение и обнаружил эту проблему. Это не имеет большого значения, но эти скобки мне кажутся неуместными. Мне потребовалось некоторое время (несколько секунд, я думаю, и тест в REPL), чтобы выяснить, какое место назначения было недопустимым. - В сообщении об ошибке указана строка за концом определения функции.

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

В отличие от этого, круглые скобки в cond = (f() && g()) мне нравятся. Думаю, я бы все равно ими воспользовался.

Как бы то ни было, я бы также предпочел and и or .

+1 от меня тоже.

Ответ почти единогласно положительный в пользу and и т. Д. Я считаю два мнения против, одно безразличное, пару неуказанных и все остальные (15 или более) за.

Один аргумент против (труднее читать) считаю неверным. Аргумент состоит в том, что foo and bar труднее читать, чем foo && bar из-за трех слов по сравнению со словом SYMBOL word. Однако все используют подсветку синтаксиса, и в этом случае происходит обратное. and окрашен как ключевое слово, поэтому a<1 and b>3 фактически раскрасит в пользу визуального разделения левого и правого подвыражений, тогда как a<1 && b>3 все три оператора будут одного цвета, подсказка потенциального приоритета оператора чесания головы.

Аргумент _for_, который еще не был представлен, заключается в том, что существует элегантная согласованность с логическими операторами, являющимися словами, поскольку результатом операции является либо true или false , то есть также слово. Так что новичку очень легко запомнить & vs and для побитового и логического. Гораздо сложнее запомнить & vs && , поскольку это кажется произвольным присвоением. Гарантированные новички будут использовать & неправильно, поскольку & передаёт слово and на английском языке. Это может вызвать ошибки приоритета (?).

Другой возможный аргумент _за_ может заключаться в том, что мозг естественным образом анализирует {НАБОР СИМВОЛОВ} слово {СУМКА СИМВОЛОВ}.

Почему бы просто не переключиться? Сейчас всегда лучшее время для этого, никогда не будет легче, чем сейчас. Исправить код, который сейчас использует &&, не так уж сложно.

Есть and or not xor может быть, nand только для полноты ?? Я не против оставить ! . Позвольте программисту выбрать, когда какой именно использовать. Ничего страшного в этом нет! При этом ! уже используется в функциях стиля foo! , поэтому есть аргумент "минимизировать повторное использование символа".

@StefanKarpinski, похоже, существует консенсус в пользу, начиная с 2013 года, я мог бы попытаться реализовать это, но я беспокоюсь, будет ли это вообще рассмотрено, поскольку этот вопрос не был закрыт, я бы предположил, что он все еще открыт для обсуждение? Использование этих слов вместо символов будет хорошо сочетаться с isa являющимся инфиксным оператором, так же, как с true , false , end и т. Д. таким образом становится более последовательным и читаемым.

+1

Просто перехожу на Юлию с Python. Похоже, Джулии грозит переполнение символов. Ради удобства чтения кода я решительно поддерживаю and и or

Поддержка ключевого слова not также может улучшить читаемость кода.

Должны ли мы осудить / запретить использование and и or (и, возможно, not ) в 0.7 / 1.0, соответственно, чтобы иметь возможность добавить их позже, если мы решим действительно нравятся им?

Я бы с этим не согласился. Бьюсь об заклад, && вместо and » для пользователей, которые пробуют операторы в стиле Python.

Я думаю, это было бы здорово!

Повторное открытие и добавление вехи, чтобы мы не забыли.

Я не понимаю цели этапа, мы собираемся добавить and и or ? мы его пересматриваем? ищете другое использование этого? Или вы имеете в виду, что собираетесь добавить устаревание, например предупреждения, чтобы люди, пришедшие из Python, знали, что нужно использовать && вместо and ?

У меня был https://github.com/JuliaLang/julia/pull/19788, в котором они были псевдонимами, но я могу изменить это, чтобы заменить их.

Эта веха должна означать: принять решение. Или, если мы не можем принять решение вовремя, откажитесь от любого использования and и or чтобы мы могли отложить решение, не рискуя впоследствии нарушить чей-либо код.

Я понимаю, что, учитывая стремление заморозить код через несколько недель, может быть уже поздно снова открывать эту банку с червями (и я ценю идею добавления амортизации, чтобы оставить дверь открытой на будущее), но одна мысль:

Когда это впервые стало предметом обсуждения (2013 г.), я думаю, что сообщество Julia состояло в основном из разработчиков - людей с сильным опытом работы в сфере CS, которые более чем привыкли использовать && и || . Я _подозреваю_, что люди, которым могут понравиться and и or больше всего относятся к прикладным пользователям, которым не так хорошо знакомы салаты ascii и которым еще предстоит потратить достаточно времени на старые языки, чтобы полностью привыкнуть к && и || . Возможно, будет интересно узнать, что люди думают по этому поводу, если мы опросим текущих пользователей Julia (особенно, если мы поднимем это на обсуждение, где это, вероятно, увидит больше людей, не являющихся разработчиками).

Было предложено зарезервировать синтаксис and , or и not . Если мы это сделаем, мы сможем добавить их в качестве операторов в любой момент временной шкалы 1.x. На данный момент никаких дальнейших обсуждений не требуется.

Я бы нормально проанализировал их как постоянные синтаксические ошибки, как мы делаем с ** . Но я все еще очень, очень против того, чтобы придавать им какой-либо смысл в противном случае.

Мне также жаль, что мы выкапываем старые проблемы, решение по которым уже принято, особенно так близко к 1.0.

Чтобы было ясно: это будет сделано, если кто-то это сделает.

Спасибо за разъяснения! : D

Мне кажется очень глупым парсить их и запрещать другое использование, и тем не менее делать это синтаксической ошибкой. Я думаю, что большинство людей предпочли бы не иметь ситуации, когда and и or являются зарезервированными словами (т.е. не могут использоваться в таких контекстах, как <strong i="7">@stackeval</strong> 1 0 and 1 or ), но не делают ничего полезного. Я бы посоветовал либо их вообще не анализировать, либо анализировать как псевдонимы (что не является необычным, поскольку это делают C и Ruby).

Мы уже решили не разбирать их как псевдонимы, поэтому ПР закрыли. Так что +1 за то, что их вообще не разбирал.

Рискуя перефразировать это обсуждение, которое было до тошноты, отмечу, что в отношении C и Ruby использование and и or в C, по моему опыту, очень необычно, и общие руководства по стилю Ruby требуют && и || вместо and и or .

ИМХО: похоже, что первоначальные дебаты были довольно раздельными, и добавление этой защиты просто оставляет место для сообщества, чтобы вернуться к ней в будущем, если они захотят.

Понятия не имею, почему это открыли снова.

Диалект Julia с синтаксическими особенностями, подобными этому, можно было бы легко создать с помощью JuliaParser.jl, как только внутренние API и API метапрограммирования стабилизируются, не могу дождаться этого! :улыбка:

Для тех, кто подошел к этой проблеме, не поняв, что произошло: хотя идея использования and и or собрала изрядную поддержку *), первый PR, который подошел к проблеме - # 19788 - в основном привело к безрезультатному обсуждению того, должны ли and и or быть прямой заменой для && и || или должны иметь немного другую семантику, например, в отношении в приоритет, но просто создание им псевдонимов было сочтено нежелательным. PR # 24965 зарезервировал бы ключевые слова (вместе с not ), чтобы дать им смысл во время цикла 1.x. Однако обсуждение во время процедуры сортировки привело к неодобрению, поэтому самое раннее, когда это могло быть пересмотрено, - это версия 2.0. (И, вероятно, потребуется привести действительно убедительные аргументы, чтобы изменение произошло тогда.)

*) Похоже, что предлагаемое изменение менее популярно среди более влиятельных / «основных» разработчиков, поэтому простой взгляд на количество 👍 может ввести в заблуждение.

Надеюсь, я не слишком упрощал и все понял правильно. Прошу прощения, если я этого не сделал.

так что самый ранний момент, когда это можно было бы пересмотреть, - это 2.0. (И, вероятно, потребуется привести действительно убедительные аргументы, чтобы изменение произошло тогда.)

Я не понимаю, почему это могло произойти, если мы уже несколько раз решили не делать этого. Я надеюсь, что мы сможем избежать повторения этой проблемы при каждом крупном выпуске.

Если Джулия продержится достаточно долго, чтобы конкурировать с Python, я могу гарантировать, что это будет появляться все больше и больше. Многие пользователи Python не хотят возвращаться к синтаксису C. Это одна из многих причин, по которым Python так популярен: прост в изучении, увлекателен в использовании, вы не захотите возвращаться к старому способу работы.

Разработчики новых языков часто заявляют, что им нужен удобный синтаксис, но они, как правило, теряются в причудливых функциях, которые когда-либо захотят или будут использовать только крошечные пользователи, при этом упускают из виду простые настройки, которые могут стимулировать принятие.

Показательный пример: поддерживаются причудливые операторы Unicode , но не естественный язык and и or .

R также использует && и || и 1-индексацию. Это не просто старые (или языки более низкого уровня, такие как C). Мне безразлично, что использовать, но это не сложнее: я научил и R, и Python закончить новичков (без разницы в программировании), и это не то, с чем они боролись. Обычно лежащие в основе концепции были более важны и требовали больше времени для изучения, чем символы или слова, используемые для написания кода. «Удобный» и «интуитивно понятный» синтаксис для вас, как для пользователя R, Python, C и т. Д., Будет отличаться просто из-за того, с чем вы уже знакомы. Это не относится к абсолютным новичкам, которых нам следует больше интересовать здесь, поскольку я думаю, что те, у кого есть опыт программирования на других языках, имеют опыт и знания, чтобы справиться с различными соглашениями на новом языке.

Единственная причина, которая, кажется, была поднята здесь, заключается в том, что Python использует and и or и тому подобное. Стоит ли это менять? Джулия не Python и не должна пытаться им стать. У нас уже есть Python. Чтобы у кого-то была мотивация перейти на новый язык, он должен быть другим. Новые пользователи Julia могут не быть программистами Python, они могут иметь опыт работы с другим языком (или вообще не иметь опыта, если он станет достаточно популярным).

Я понимаю, что это, вероятно, мертвая проблема, но в ответ на @TomKellyGenetics я бы предположил, что IMHO многие из нас будут утверждать, что R квалифицируется как «старый», и он не особенно && Операторы and , or ) более знакомыми и удобочитаемыми, независимо от того, являются ли они Python пользователи или нет.

R также использует && и || и 1-индексация. Это не просто более старые (или более низкие) языки, такие как C).

Я имел в виду C-подобные языки, то есть языки, которые в значительной степени заимствуют синтаксис из C, обычно с самореализующимся аргументом «это синтаксис, который использует любой другой язык». Синтаксис R скорее похож на C, хотя кое-где он и расходится. Julia больше похожа на Fortran, чем на C, хотя есть некоторые совпадения.

Я обучал и R, и Python для начинающих (без разницы в программировании), и это не то, с чем они боролись.

Студенты IME, плохо знакомые с программированием, в первую очередь борются с синтаксисом, это смерть от тысячи сокращений. Программирование чуждо, и выбор абстрактных символов вместо естественного языка делает его еще более чуждым и легко забываемым. Я часто слышу, как новички в C-подобных языках спрашивают: «Как ты пишешь» или «еще раз?»
Но естественный язык в программировании - это проблема не только для новичков. Даже опытные программисты с большей вероятностью пропустят ! вместо not , и многим легче ускорить чтение и набрать or и and вместо || и && .

Джулия не Python и не должна пытаться им стать. У нас уже есть Python. Чтобы у кого-то была мотивация перейти на новый язык, он должен быть другим.

Джулия тоже не C или Фортран. Подавляющее большинство популярных языков являются C-подобными, поэтому выделиться обычно означает делать что-то отличное от C. Мне на самом деле нравятся Fortran, C и их потомки, я использую их все время, но в некоторых местах они не справляются, и я думаю, что мы можем сделать лучше. Один из способов - использовать более естественный язык. Стоит отметить, что Fortran 77 и выше для хорошего эффекта используют .not. , .and. и .or. . В этом смысле я действительно хочу, чтобы Джулия была больше похожа на Фортран, а не на Си!

Проблема была решена; and и or разрешены в качестве идентификаторов, и мы продолжим использовать && и || для потока управления. Я не уверен, почему это все еще обсуждается.

Существует тенденция переоценивать важность поверхностных синтаксических проблем, поскольку они хорошо заметны, легко обсуждаются и их последствия обычно ясны. В другой сфере язык считается непригодным для использования, если блоки кода не окружены фигурными скобками, и в этом случае и julia, и python выходят за рамки рамок.

Я считаю спорным, действительно ли a and b читабельнее, чем a && b . && выделяется больше. Тот факт, что || и && имеют одинаковую длину, также может улучшить форматирование. Одна из причин, по которой символы операторов, такие как a = b и a + b работают так хорошо, заключается в том, что они добавляют визуальную структуру поверх чего-то вроде set a to b . a[i] или element i of a ?

вы не захотите вернуться к старому образу жизни.

Для меня старый способ работы - это ручное управление памятью и слабая поддержка полиморфизма, а не написание && .

У Джулии есть несколько выражений на естественном языке, например for a in [1, 2, 3] . Он читается лучше и более интуитивно понятен, чем for a = [1, 2, 3] , который также поддерживает Джулия. Я бы, конечно, не предлагал предоставлять альтернативы на естественном языке для всех символических операторов, только для тех немногих, которые делают Джулию более интуитивно понятной и удобочитаемой.

FWIW, я проголосовал за использование обоих наборов операторов, чтобы облегчить внедрение и предоставить пользователям выбор стиля. В проектах C ++, где люди используют и то, и другое, меня это никогда не беспокоило. Я не вижу в этом вреда, только пользу.

В целом мне нравится направление, в котором изменился синтаксис Джулии. Отличный баланс между естественным языком и символами доказывает, что числовой язык может преуспеть в программировании общего назначения. Не могу дождаться, чтобы увидеть, как он растет и развивается. Это мой способ сказать, что добавление операторов естественного языка технически обратно совместимо. :ухмылка:

Я сделаю попытку зарезервировать or , and и not для возможного использования в будущем, а также сделаю предупреждение / предложение использовать соответствующие символы. Что мне делать в Julia 0.7, 1.0 или обоих?

24965?

Ах, пропустил, спасибо! Я полагаю, что отказ от резервирования ключевых слов не мешает поддерживать эти ключевые слова в будущем.

Извините, прочитал все обсуждения, но все еще не понял, как я могу использовать and , or в Julia сейчас?

Ты не можешь