Чому підтипування поведінки не можна визначити?

Робота Ліскова в цій галузі була зосереджена на поведінковому підтипу, який, окрім безпеки системи безпеки, розглянутий у цій статті, також вимагає, щоб підтипи зберігали всіх інваріантів, гарантованих супертипами в якомусь договорі. [3] Це визначення підтипу, як правило, не можна визначити, тому воно не може бути перевірене засобом перевірки типу.

Від: http://www.wikiwand.com/en/Subtyping#/Function_types

type-systems subtypes

— q126y
джерело

Відповіді:

Нехай контракт на експлуатацію oType Tбуде таким, що він зупиняє всі входи. Тепер вирішіть, чи oвідповідає функція підтипу S <: Tцьому контракту: ви щойно вирішили проблему зупинки .

Більш загально, S::oслід обчислити ту саму функцію, як T::oніби S <: T. Вирішення того, чи дві програми обчислюють одну і ту ж функцію, називається Проблема функції і еквівалентна вирішенню проблеми зупинки.

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

— Йорг W Міттаг
джерело

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

— Бенджамін Грюнбаум

@BenjaminGruenbaum Jorg відповідь та ваш коментар правильні, але є тонкощі до цього, я хотів би уточнити. Часто можливо довести властивість щодо конкретної програми. Просто не існує алгоритму, за яким можна сліпо слідувати, який буде працювати для всіх програм. Розглянемо цей метод, написаний на Java:

BigInteger sum(int[] arr) { BigInteger sum = BigInteger.ZERO; for (int x: arr) sum = sum.add(BigInteger.valueOf(x)); return sum; }

Не важко довести, що конкретний метод завжди повертає суму елементів цілого масиву і не робить нічого іншого (за умови, що аргумент не є нульовим).

— Довал

І коли це не рівнозначно проблемі зупинки, це часто навіть гірше . Тому що неможливо вже не було досить важким.

— user2357112 підтримує Моніку

Або кажучи про точку Доваля іншим (тупим) способом, саме тому цікаві та корисні нестандартні мови. Для реальної роботи вам часто не потрібна Тьюрінг-повнота (безумовно, на рівні модуля).

— Левшенко

@Doval: Дуже хороший момент. Хоча це правда, що ви не можете мати алгоритм, який підтверджує завершення та / або правильність випадкової програми, можна записати програми таким чином, щоб ви могли довести їх правильність.

— Джорджо

Тому що майже кожне запитання про поведінку програм не можна вирішити. За теоремою Райса будь-яка проблема рішення форми:

Деякі програми обчислюють функції, які мають це властивість, інші програми обчислюють функції, які не мають цього властивості. Враховуючи програму P, чи має обчислена P функція вищезазначене властивість чи ні?

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

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

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

— Натан Туггі