Почему языки не включают импликацию как логический оператор?

Это может быть странный вопрос, но почему во многих языках нет смысла в качестве логического оператора (Java, C, C ++, Python Haskell - хотя, как и в прошлом, пользовательские операторы добавили его тривиально, чтобы добавить его)? Я считаю, что логическое значение гораздо яснее писать (особенно в утверждениях или выражениях, подобных утверждениям), а затем отрицание с помощью или:

encrypt(buf, key, mode, iv = null) {
    assert (mode != ECB --> iv != null);
    assert (mode == ECB || iv != null);
    assert (implies(mode != ECB, iv != null)); // User-defined function
}

Это может быть полезно иметь иногда, без сомнения. Несколько аргументов против такого оператора:

• Персонажи -и >являются ценными, как в отдельности, так и в сочетании. Многие языки уже используют их для обозначения других вещей. (И многие не могут использовать наборы символов Юникода для своего синтаксиса.)
• Импликация очень нелогична даже для логически настроенных людей, таких как программисты. Тот факт, что три из четырех записей таблицы истинности являются trueудивительными для многих.
• Все остальные логические операторы симметричны, что сделало бы ->исключение ортогональности.
• В то же время существует простой обходной путь: используйте операторы !и ||.
• Импликация используется значительно реже, чем логическая and/ or.

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

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

Это предложение I главы II из книги Джорджа Буля « Исследование законов мышления» (1854) :

Все операции языка, как инструмент рассуждения, могут проводиться системой знаков, состоящей из следующих элементов, а именно:

Первый. Буквенные символы, такие как х, у и т. Д., Представляющие вещи как предметы наших концепций.

Второй. Признаки действия, такие как +, -, ×, обозначают те действия разума, с помощью которых концепции вещей объединяются или разрешаются, образуя новые концепции, включающие одни и те же элементы.

Третий. Знак идентичности, =.

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

Знак + логического выражения представляет ту же самую «операцию разума», которую мы сегодня признаем как логическое «или» и объединение множеств. Точно так же знаки - и × соответствуют нашему логическому отрицанию, дополнению множества, логическому «и» и пересечению множеств.

ОБНОВЛЕНИЕ: Этот вопрос был темой моего блога в ноябре 2015 года . Спасибо за интересный вопрос!

Visual Basic 6 (и VBScript) имел Impи Eqvоператоры. Никто не использовал их. Оба были удалены в VB.NET; Насколько мне известно, никто не жаловался.

Я работал в команде компилятора Visual Basic (в качестве стажера) целый год и ни разу не заметил, что у VB даже были эти операторы. Если бы я не был парнем, пишущим компилятор VBScript, и поэтому должен был бы протестировать их реализации, я, вероятно, не заметил бы их. Если парень из команды компиляторов не знает о функции и не использует ее, это говорит вам о популярности и полезности этой функции.

Вы упомянули C-подобные языки. Я не могу говорить с C или C ++ или Java, но я могу говорить с C #. Существует список предлагаемых пользователем функций для C # буквально длиннее вашей руки. Насколько мне известно, ни один пользователь никогда не предлагал такой оператор команде C #, и я просматривал этот список много, много раз.

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

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

if (mode != ECB) assert (iv != null);

assert (mode != ECB --> iv != null);  // <-- that's only one character shorter

Если вам нужно выражение, можно использовать встроенный оператор if, доступный в большинстве языков (часто называемый троичным оператором). Конечно, это не так элегантно, как A --> B, но количество вариантов использования может не оправдать добавление (и сохранение!) Другого оператора:

assert (mode != ECB ? iv != null : true);

Эйфелева имеет значение

На самом деле есть даже больше. У этого есть много полужестких операторов так же как строгих.

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

Оказывается, если у вас есть язык с такими булевыми операторами, и вы знаете, как проектировать их и использовать их, тогда вы их используете.

В Eiffel использование ключевого слова «подразумевает» является довольно заметным из-за Design-by-Contract из-за булево-тяжелого характера утверждений контракта. Есть некоторые контракты, которые могут быть написаны правильно и эффективно только с оператором «подразумевает». Затем напрашивается комментарий о том, что языки без контрактов не имеют смысла смотреть, обучать и реализовывать использование импликации.

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

Вместо этого люди, работающие с компилятором, должны вернуться к теории, написать обозначение языка, которое предлагается или подразумевается теорией (например, объектно-ориентированная теория), независимо от того, что думают или просят немытые массы программистов. Оттуда профессорам, учителям и другим специалистам необходимо профессионально обучать молодых людей, основанных на необработанной теории, а не на «теории через линзу языка». Когда это происходит, люди внезапно просыпаются и осознают, чего им не хватало и что им навязали.

Прямо сейчас - существует так много теории, которая маскируется под Объектно-Ориентированную, но это просто "сквозь стекло, мрачно-оф-твои". Никто не может прочитать большинство «теоретических» книг по ОО, потому что они хотят интерпретировать, что такое теория, через призму какого-то языка. Совершенно неверно и неверно. Это все равно что учить математике на калькуляторе или правилам скольжения. НЕТ - человек позволяет реальности учить себя самому, а затем использует нотацию для описания того, что он наблюдает - это называется «наука». Эта другая смесь, называемая OO-based-on-language-X, настолько искажена, что едва ли представляет реальность.

Итак, отойдите от языка, взгляните на грубую теорию и начните снова. Не позволяйте ограничениям, ограничениям и рисованиям языка говорить вам, что такое теория. Просто позвольте реальности теории диктовать свои собственные обозначения, а затем перейти к формулировке языка.

Оттуда вы начнете понимать, как подтекст и «намеки» не только полезны, но и элегантны и очень круты!

Хорошего вам!

У Python есть оператор импликации в некотором скрытом виде.

Оператор «меньше или равно» перегружен для принятия логических значений. В результате его можно использовать как оператор импликации.

Доказательство примером (код Python):

print (False <= False) # This will print True.
print (False <= True)  # This will print True.
print (True <= False)  # This will print False.
print (True <= True)   # This will print True.

Напомним, таблица истинности оператора импликации:

LEFT RIGHT RESULT
F    F     T
F    T     T
T    F     F
T    T     T

У Eiffel есть оператор «подразумевает», и он очень хорош для написания предварительных и постусловий. Это делает код более читабельным, к сожалению, это никогда не было фундаментальным намерением для языка, подобного C, и слишком мало людей использовали eiffel, поэтому красота выражения «подразумевается» как оператора недостаточно известна.

Для меня большая проблема со значением подразумевается, когда начальное условие ложно; например: «Если солнце зеленое, то я фруктовая летучая мышь». Правда!

В формальной логике он просто назначает значение «Истина», когда условие импликации не выполняется. Но в программировании это может привести к противоречивым и удивительным результатам.

Я действительно думаю, что пример @Heinzi дает выше:

if (sun.color() == "green") then assert(me.species() == "fruitbat")

Это гораздо проще для понимания и менее подвержено ошибкам из-за неправильного понимания логики.

В контексте тестирования я бы просто остановился, как только мои предположения стали ложными:

assert(sun.color() == "green")
assert(me.species() == "fruitbat")

Так что, к слову @Eric Lippert, как программист, я не знаю, когда бы я использовал оператор подразумеваемого. Поведение «False is True» кажется полезным в контексте математической, формальной логики, но может привести к неожиданным результатам в логике программы.

...

Никто не упомянул общее "?" оператор, где «A? B: true» совпадает с «подразумевает». Но в то время как формальная логика присваивает true условию else, «?» позволяет разработчику назначить это явно.

В формальной логике использование «true» работает, но в программировании, если условие ложно, тогда лучший ответ больше похож на «null» или «void», или «skip», или даже может быть false.

Я думаю, что кто-то должен был бы объяснить, почему «подразумевает» более полезный оператор, чем операторы «?» Или «если», или просто обычный программный поток.

Ракетка имеет implies. Макро-расширяется до ifвыражения.