Что на самом деле должно быть доказательством правильности проверки типов?

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

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

Говоря простым языком, я хочу, чтобы моя программа проверки типов могла выявлять любые ошибки в фрагменте кода, которые могут возникнуть во время выполнения. Если бы я использовал что-то вроде Coq, чтобы попытаться доказать, что моя реализация верна, что именно будет пытаться показать это «доказательство правильности»?

Вопрос можно интерпретировать двумя способами:

• Реализует ли реализация заданную систему типирования ?$T$
• $T$

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

$T$$T$

• Во-первых, вы формально определяете, что означает для программы немедленное опечатывание . Это можно определить многими способами - решать только вам. Как правило, мы хотим предотвратить такие программы, как 2 + "hello". Другими словами, вам нужно определить подмножество программ, назовите их Bad , которые содержат именно программы с немедленной ошибкой ввода.

• $\Gamma \vdash M : \alpha.$$M$$\alpha$$\Gamma$

  $\Gamma \vdash M : \alpha$$M \rightarrow \cdots \rightarrow N$$N \notin$

  Как доказать эту теорему, зависит от деталей языка, системы набора текста и вашего выбора Bad .

$M$$M \rightarrow N$$M$

• $\Gamma \vdash M : \alpha$$M \rightarrow N$$\Gamma \vdash N : \alpha$

• $\Gamma \vdash M : \alpha$$M$

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

Это хороший вопрос! Он спрашивает, что мы ожидаем от типов в типизированном языке.

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

$e$$A$$e$$A$$A$int

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

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

• более выразительные типы позволяют нам более подробно объяснить (себе и компилятору), что должно происходить
• более простые типы легче понять и их легче автоматизировать в компиляторе. (Люди придумывают типы, которые по существу требуют помощника по проверке и ввода пользователя для проверки типов.)

Простота не следует недооценивать, так как не каждый программист имеет докторскую степень по теории языков программирования.

Итак, давайте вернемся к вашему вопросу: откуда вы знаете, что ваша система типов хороша ? Ну, докажите теоремы, которые показывают, что ваши типы сбалансированы. Будет два вида теорем:

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

2. Теоремы, которые говорят, что ваши типы просты . Основным было бы то, что можно решить, имеет ли данное выражение заданный тип. Еще одна особенность простоты - предоставить алгоритм для вывода типа. Другие теоремы о простоте могут заключаться в том, что выражение имеет не более одного типа или что выражение имеет основной тип (т. Е. «Лучший» среди всех типов, которые оно имеет).

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

Есть несколько разных вещей, которые вы могли бы иметь в виду под «доказать, что мой проверщик типов работает». Что, я полагаю, является частью того, что задает ваш вопрос;)

Половина этого вопроса доказывает, что ваша теория типов достаточно хороша, чтобы доказать любые свойства языка. Ответ Андрея очень хорошо справляется с этой задачей. Другая половина вопроса - предположим, что язык и его система типов уже исправлены - как вы можете доказать, что ваша конкретная программа проверки типов действительно правильно реализует систему типов? Есть две основные перспективы, которые я вижу здесь.

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

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