Почему поведенческий подтип неразрешим?

Работа Лискова в этой области была сосредоточена на поведенческих подтипах, которые помимо безопасности системы типов, обсуждаемой в этой статье, также требуют, чтобы подтипы сохраняли все инварианты, гарантируемые супертипами в некоторых контрактах. [3] Это определение подтипа обычно неразрешимо, поэтому его нельзя проверить с помощью средства проверки типов.

От: http://www.wikiwand.com/en/Subtyping#/Function_types

type-systems subtypes

— q126y
источник

Ответы:

Пусть контракт работы oType Tбудет таким, что он останавливается для всех входов. Теперь решите, удовлетворяет ли операция oподтипа S <: Tэтому контракту: вы только что решили проблему остановки .

В более общем случае, S::oдолжны вычислять ту же функцию, как T::oесли бы S <: T. Решение о том, будут ли две программы вычислять одну и ту же функцию, называется функциональной проблемой и эквивалентно решению проблемы остановки.

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

— Йорг Миттаг
источник

Эта последняя строчка прибивает это. В тот момент, когда вы хотите доказать, что программа может делать в поведенческих условиях, вы вступаете в невозможное. Система типов и инструменты статического анализа работают по той причине, что они относятся к другому языку (типам программы, области видимости переменных в программе и т. Д.), А не к свойствам непосредственного запуска программы .

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

@ BenjaminGruenbaum Ответ Йорга и ваш комментарий верны, но есть тонкость, которую я хотел бы уточнить. Часто можно доказать свойство о конкретной программе. Просто нет алгоритма, который вы можете слепо следовать, который будет работать для всех программ. Рассмотрим этот метод, написанный на Java:

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

нетрудно доказать, что конкретный метод всегда возвращает сумму элементов целочисленного массива и ничего не делает (при условии, что аргумент не равен нулю).

— Доваль

А когда это не эквивалентно проблеме остановки, часто это еще хуже . Потому что невозможное уже не было достаточно сложным.

— user2357112 поддерживает Monica

Или поставить точку Doval в другой (тупой) способ, именно поэтому не являющиеся -Turing полные языки интересны и полезны. Вам часто не нужна полнота Тьюринга (конечно, на уровне модуля) для реальной работы.

— Леушенко

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

— Джорджио

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

Некоторые программы вычисляют функции, которые имеют это свойство, другие программы вычисляют функции, которые не имеют этого свойства. Имеет ли программа P заданную выше функцию для данной программы P, или нет?

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

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

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

— Натан Тагги