Чому мови не включають значення як логічний оператор?

Це може бути дивним питанням, але чому немає ніяких наслідків як логічного оператора для багатьох мов (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
}

Це може бути корисно інколи, без сумніву. Проти такого оператора заперечують декілька пунктів:

• Характери -і >цінні, як ізольовано, так і поєднані. Багато мов уже використовують їх для позначення інших речей. (І багато хто не може використовувати набори символів unicode для свого синтаксису.)
• Наслідки є дуже протиінтуїтивними, навіть для логічно налаштованих людей, таких як програмісти. Той факт, що три з чотирьох записів таблиці істинності trueвикликає здивування багатьох.
• Усі інші логічні оператори симетричні, що могло б зробити ->виняток з ортогональності.
• У той же час існує просте вирішення: використовувати оператори !та ||.
• Імплікація використовується набагато рідше, ніж логічна and/ or.

Можливо, тому оператор сьогодні рідкісний. Звичайно, це може стати більш поширеним, оскільки нові динамічні мови використовують Unicode для всього, а перевантаження оператора знову стає модною.

Я вважаю, що відповідь лежить у математичних засадах . Наслідки зазвичай розглядаються і визначаються як похідна, не елементарна, операція булевих алгебр. Мови програмування дотримуються цієї конвенції.

Це пропозиція I глави II з " Дослідження законів думки Джорджа Була" (1854) :

Усі операції з мовою як інструмент міркування можуть здійснюватися системою знаків, що складається з таких елементів, а саме:

1-й. Буквальні символи, як x, y та c., Представляють речі як предмети наших уявлень.

2-й. Ознаки дії, як +, -, ×, стоять для тих операцій розуму, за допомогою яких уявлення про речі поєднуються або вирішуються так, щоб утворювати нові уявлення, що включають ті ж елементи.

3-й. Знак тотожності, =.

І ці символи Логіки у своєму використанні підлягають певним законам, частково узгоджуючись і частково відрізняючись від законів відповідних символів у науці про Алгебру.

Знак Була + являє собою ту саму "операцію з розумом", яку ми сьогодні визнаємо як булевою "чи", так і об'єднанням множин. Аналогічно знаки - і × відповідають нашому булевому запереченню, доповненню множини, булевому «і» та перетину множин.

ОНОВЛЕННЯ: Це питання було предметом мого блогу в листопаді 2015 року . Дякую за цікаве запитання!

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

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

Ви згадали мови, схожі на С Я не можу спілкуватися з C або C ++ або Java, але можу говорити на C #. Існує список запропонованих користувачем функцій для C # буквально довше, ніж ваша рука. Наскільки мені відомо, жоден користувач ніколи не пропонував такого оператора команді C #, і я переглядав цей список багато, багато разів.

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

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

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

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

Якщо вам потрібен вираз, може бути використаний оператор вбудованого інтерфейсу, який доступний на більшості мов (його часто називають потрійним оператором). Зрозуміло, це не так елегантно A --> B, але кількість випадків використання може не виправдати додавання (та підтримку!) Іншого оператора:

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

Ейфель має наслідки

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

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

Виявляється, що коли ти володієш мовою з такими булевими операторами і знаєш, як з ними конструювати та використовувати, то ти їх використовуєш.

В Ейфелі використання ключового слова "мається на увазі" є досить помітним через проектування за контрактом через булевий характер контрактних тверджень. Існують деякі договори, які можна правильно та ефективно скласти лише з оператором "передбачає". Потім напрошується зауважити, що мови без контрактів надалі без приводу шукати, навчати та застосовувати використання наслідків.

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

Натомість людям-компіляторам необхідно створити резервну копію теорії, написати мовну нотацію, яку теорія пропонує чи передбачає (наприклад, Об'єктно-орієнтована теорія) незалежно від того, що думають чи просять немиті маси програмістів. Звідти професорам, викладачам та іншим професіоналам потрібно професійно навчати молодих мухоморів, заснованих на сирій теорії, а НЕ "теорії через мову". Коли це станеться, люди раптом прокинуться і зрозуміють, чого вони пропустили і що на них сфокусовано.

Наразі - існує стільки теорії, яка маскується під об'єктно-орієнтований, але це просто OO-через-склянку-темно-на- [вибери свою мову]. Не можна читати більшість «теоретичних» книг про ОО, оскільки вони хочуть інтерпретувати те, що ця теорія є через об'єктив якоїсь мови. Повністю помилкові та невірні. Це було б як викладання математики на основі мого калькулятора чи мого правила слайдів. НІ - дозволяє дійсності навчити себе про себе, а потім використовує позначення для опису того, що спостерігається - це називається "наука". Цей інший маш, який називається OO на основі мови-X, настільки перекошений, що ледве представляє реальність.

Отже, відійдіть від мови, погляньте на сиру теорію і почніть знову. Не дозволяйте обмеженням, обмеженням і фарбам завдань мови говорити про те, що таке теорія. Просто нехай реальність теорії диктує власне позначення, а потім перейдемо звідти до формулювання мови.

Звідти ви почнете отримувати, як підказки та "натяки" не тільки корисні, але й елегантні та дуже класні!

Майте чудовий!

У Python є оператор імплікації якось прихованим чином.

Оператор, менший за рівний або рівний, перевантажений, щоб прийняти булеві значення. Як результат, можна використовувати його в якості оператора імплікацій.

Доказ на прикладі (Python Code):

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

У Ейфеля є оператор "мається на увазі", і це дуже приємно для написання попередніх та постумов. Це робить код більш читабельним, на жаль, що ніколи не було принциповим наміром для мови на зразок C, і надто мало людей використовували ейфель, тому краса "передбачає", як оператор недостатньо відомий.

Для мене велика проблема із наслідками виникає тоді, коли початкова умова хибна; наприклад: "Якщо сонце зелене, то я - фруктова кажан". Правда!

У формальній логіці він просто працює, щоб призначити "True" значенням, коли умова імплікації не виконується. Але в програмуванні це може призвести до контрінтуїтивних та дивних результатів.

Я насправді думаю, що приклад @Heinzi дає вище:

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

Значно простіше зрозуміти і менш схильний до помилок через нерозуміння логіки.

У контексті тестування я просто зупинив момент, коли мої припущення стали помилковими:

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

Тож, на думку @Eric Lippert, як програміста я не знаю, коли б я використовував оператора, що має на увазі. Поведінка "Неправдива правда" здається корисною в контексті математичної, формальної логіки, але може призвести до несподіваних результатів у логіці програми.

...

Ніхто не згадав загальне "?" оператор, де "A? B: true" - це те саме, що "має на увазі". Але поки формальна логіка привласнює істину умові "else", "?" дозволяє розробнику явно призначити це.

У формальній логіці використання "true" працює, але в програмуванні, якщо умова хибна, то краща відповідь більше схожа на "null" або "void" або "skip", а може бути, і false.

Я думаю, що комусь доведеться зробити випадок, чому "мається на увазі" є більш корисним оператором, ніж заяви "?" Або "якщо", або просто регулярний потік програми.

Ракетка має implies. Він макророзширюється на ifвираз.