Неявне проти явного підтипу

Ця сторінка стверджує, що

багато мов не використовують неявне підтипування (структурна еквівалентність), віддаючи перевагу явному / оголошеному підтипу (еквівалентність декларації)

Я в основному використовував мови програмування, які використовують явні підтипи . Які переваги неявного підтипу, як описано в примітках вище.

pl.programming-languages type-theory

— Френкі Рібері
джерело

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

— Девід Еппштейн

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

— Ніл Крішнасвамі

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

— Ноам Зейльбергер

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

— Neel Krishnaswami

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

— Девід Еппштейн

Відповіді:

Коротка відповідь - "перевірити додаткові властивості існуючого коду". Випливає довша відповідь.

Я не впевнений, що "неявна" проти "явна" є хорошою термінологією. Це відмінність іноді називають "структурним" проти "номінального" підтипу. Тоді також є друга відмінність у можливих інтерпретаціях структурного підтипу (описано коротко). Зауважте, що всі три трактування підтипів насправді є ортогональними, і тому насправді не має сенсу порівнювати їх один з одним, а не розуміти використання кожного з них.

Основна операційна відмінність інтерпретації структурного відношення підтипу A <: B полягає в тому, чи свідчить він про реальний примус з обчислювальним змістом (час виконання / компіляція), чи може бути свідком примусу ідентичності. Якщо першою, важливою теоретичною властивістю, яка має володіти, є "когерентність", тобто, якщо існує кілька способів показати, що A є підструктурним підтипом B, кожна з супутніх коеркцій повинна мати однаковий обчислювальний зміст.

Надане вами посилання, мабуть, має на увазі другу інтерпретацію структурного підтипу, де A <: B може бути свідком примусу ідентичності. Іноді це називається "підмножиною інтерпретації" підтипу, приймаючи наївне уявлення про те, що тип являє собою набір значень, і тому A <: B на всякий випадок, якщо кожне значення типу A також є значенням типу B. Це також іноді називають "уточненням набору тексту", і гарним документом для читання для оригінальної мотивації є типи доопрацювання Freeman & Pfenning для ML . Для більш недавнього втілення у F # ви можете прочитати Bengston et al., « Уточнення» для безпечних реалізацій. Основна ідея - взяти існуючу мову програмування, яка може (або не може) вже мати типи, але в яких типи не гарантують все так багато (наприклад, лише безпека пам’яті), і розглянути другий рівень типів, вибираючи підмножини програм з додаткові, точніші властивості.

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

— Ноам Зейльбергер
джерело

A \times B \times C <: A \times B

$A \times B \times C <: A \times B$

C

$C$

A

$A$

B

$B$

Завдання оптимізатора - визначити оптимальне розташування пам’яті, тому коеркіони, які є ідентичністю, справді повинні бути результатом оптимізації.

— Андрій Бауер

тож просто для уточнення коментаря Андрія стосовно моєї відповіді, в уточненій інтерпретації введення тексту, стосунки підтипів завжди свідчать про примушення ідентичності за визначенням , тому що типи уточнення не мають додаткового обчислювального змісту. Іншими словами, якщо A і B - це два уточнення ("підмножини" / "властивості") типу значень X, A <: B стверджує, що для кожного значення x в X, якщо x: A, то також x: B. Таке твердження можна перевірити або підробити, але воно не впливає на час виконання, оскільки докази того, що x: A і x: B не існують під час виконання.

— Ноам Зейльбергер

N

$\mathbb{N}$

{x : N | x < 2^{32}}

$\{x:N\;\;|\;\;x < 2^{32}\}$

@Neel: Я поділив би його на два етапи, 1. застосуйте безвирахувальний примус ідентичності від

до його уточнення

N

$N$

{x : N | x < 2^{32}}

$\{x:N | x < 2^{32}\}$

N

$N$

{x : N | x < 2^{32}}

$\{x:N | x < 2^{32}\}$

— Ноам Зейльбергер

Ця відповідь є своєрідним мінімальним доповненням до відмінної відповіді Ноама. Однією із цікавих даних є доля концепцій C ++, які були засновані на спробі уніфікації номінальних та структурних понять типу.

Тут є чудовий опис із посиланнями на більшу частину відповідної дискусії: http://bartoszmilewski.wordpress.com/2010/06/24/c-concepts-a-postmortem/

Однак вищеописаний опис не обговорює номінальну та структурну проблему жодної глибини. Тут є ще одна реєстрація: http://nerdland.net/2009/07/alas-concepts-we-hardly-knew-ye/

Основний документ, на який вказують, - "Спрощення використання понять" Б'ярна Струструпа: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2906.pdf , який переходить у практичну проблеми, з якими стикаються в деякій глибині.

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

— sclv
джерело