Що насправді має підтверджувати правильність для перевірки набору тексту?

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

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

Простий мовою, я хочу, щоб моя перевірка типу могла ідентифікувати будь-які помилки в фрагменті коду, які можуть виникнути під час виконання. Якщо я використовую щось на зразок Coq, щоб спробувати довести, що моя реалізація правильна, що саме намагатимуться показати цей "доказ коректності"?

Питання можна трактувати двома способами:

• Чи реалізація реалізує задану систему набору тексту ?$T$
• Чи запобігає система набору тексту , які помилки, на вашу думку, повинні?$T$

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

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

• По-перше, ви формально визначаєте, що означає для програми негайна помилка введення тексту . Існує багато способів, як це можна визначити - це вирішувати саме вам. Зазвичай ми хочемо запобігти такі програми 2 + "hello". Іншими словами, вам потрібно визначити підмножину програм, назвати їх Bad , що містить саме програми з негайною помилкою введення тексту.

• Тоді ви повинні довести, що програми, які можна набрати, ніколи не можуть перетворюватися на програми в Bad . Давайте формалізуємо це. Нехай ваше судження про введення тексту буде Нагадаємо, що це слід читати як: програма M має тип α , припускаючи, що вільні змінні вводяться так, як задано середовищем Γ . Тоді теорема, яку ви хочете довести:$\Gamma \vdash M : \alpha.$$M$$\alpha$$\Gamma$

  Теорема. Всякий раз, коли і M → ⋯ → N, тоді N ∉ Bad .$\Gamma \vdash M : \alpha$$M \rightarrow \cdots \rightarrow N$$N \notin$

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

Один стандартний спосіб визначення Bad є: термін має безпосереднє повідомлення про помилку типу , якщо вона НЕ є ні значення , ні має стадію відновлення M → N . (У цьому випадку М часто називають застряглим .) Це працює лише для оперативної семантики невеликих ступенів. Один із стандартних способів доведення теореми - це показати$M$$M \rightarrow N$$M$

• і M → N разом означають Γ ⊢ N : α . Це називається "зменшення предмета". Зазвичай це доводиться одночасним спонуканням до виведення судження про введення тексту та тривалості скорочень.$\Gamma \vdash M : \alpha$$M \rightarrow N$$\Gamma \vdash N : \alpha$

• Всякий раз, коли тоді M не є поганим . Зазвичай це також доводиться шляхом спонукання до виведення судження про введення тексту.$\Gamma \vdash M : \alpha$$M$

Зауважте, що не всі системи набору тексту мають "зменшення теми", наприклад типи сеансів. У цьому випадку потрібні більш складні методи доказування.

Це гарне запитання! Він запитує, чого ми очікуємо від типів у набраній мові.

Спершу зауважте, що ми можемо набрати будь-яку мову програмування у юнипе : просто виберіть букву, скажімо U, і скажіть, що кожна програма має тип U. Це не дуже корисно, але це має сенс.

Існує багато способів зрозуміти типи, але з точки зору програміста наступне, я вважаю корисним. Подумайте про тип як специфікацію чи гарантію . Для того, щоб сказати , що має тип А це означає , що «ми гарантуємо / очікування / попиту , що е задовольняє властивість кодованого А ». Часто A - це щось просте на кшталт , у цьому випадку властивість просто "це ціле число".$e$$A$$e$$A$$A$int

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

Мистецтво типів в дизайні мови програмування - це врівноваження виразності та простоти :

• більш виразні типи дозволяють нам детальніше пояснити (собі та компілятору), що має йти далі
• простіші типи простіші для розуміння і їх легше автоматизувати в компіляторі. (Люди придумують типи, які, по суті, потребують асистента і кореспондента користувача для перевірки типу.)

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

Тож повернемося до вашого питання: як ви знаєте, що ваша система типу хороша ? Ну, доведіть теореми, які показують, що ваші типи мають бути врівноваженими. Існуватиме два види теорем:

1. Теореми, які говорять про те, що ваші типи корисні . Знання, що програма має тип, має передбачати певні гарантії, наприклад, що програма не зациклюється (це буде теоремою безпеки ). Інша сім'я теорем з'єднала б типи з семантичними моделями, щоб ми могли почати використовувати реальну математику для доведення речей про наші програми (це були б теореми про адекватність та багато інших). Зверху єдність погана, оскільки не має таких корисних теорем.

2. Теореми, які говорять про те, що ваші типи прості . Основним з них буде те, що вирішується, чи має певний вираз даний тип. Ще одна особливість простоти - дати алгоритм для виведення типу. Інші теореми про простоту полягають у тому, що вираз має максимум один тип, або що вираз має головний тип (тобто, "найкращий" серед усіх типів, які він має).

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

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

Половина цього питання доводить, що теорія вашого типу є достатньо хорошою для підтвердження будь-яких властивостей мови. Відповідь Андрія вирішує цю область дуже добре. Друга половина питання - якщо запропонувати мову та систему її типів уже виправлені - як ви можете довести, що ваша конкретна перевірка типів насправді правильно застосовує систему типів? Тут я бачу дві основні перспективи.

Перше: як ми можемо вірити, що якась конкретна реалізація відповідає її специфікації? Залежно від ступеня впевненості, яку ви хочете, ви можете бути задоволені великим тестовим набором, або ви хочете отримати якусь офіційну перевірку або, швидше за все, суміш обох . Перевага цієї точки зору полягає в тому, що вона дійсно підкреслює важливість встановлення меж для заяв, які ви пред'являєте: що саме означає "правильне"? яка частина коду перевірена, проти якої частини вважається правильним TCB? Мінус полягає в тому, що занадто важке роздуми над цим призводить до філософських кролячих дірок - ну, " вниз ", якщо вам не подобаються ці кролячі нори.

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