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

Якщо коротко: як класифікуються системи типів в академічному контексті; зокрема, де я можу знайти авторитетні джерела, які роблять чіткими відмінності між різними типами системи?

У певному сенсі складність цього питання полягає не в тому, що я не можу знайти відповідь, а в тому, що я можу знайти занадто багато, і жодне не виділяється як правильне. Фон полягає в тому, що я намагаюся вдосконалити статтю у вікі Haskell про введення тексту , яка наразі вимагає таких відмінностей:

• Немає введення тексту: Мова не має поняття типів або з введеної точки зору. У мові існує точно один тип. Мова складання має лише тип 'бітовий шаблон', у Rexx та Tk є лише тип 'текст', в ядрі MatLab є лише тип 'складнозначна матриця'.
• Слабке введення тексту: Є лише кілька виділених типів і, можливо, введіть синоніми для кількох типів. Напр. C використовує цілі числа для булевих, цілих чисел, символів, наборів бітів та перерахувань.
• Сильне введення тексту: Дрібнозернистий набір типів, таких як ада, віртська мова (Паскаль, Модула-2), Ейфелева

Це цілком суперечить моєму особистому сприйняттю, яке більше відповідало:

• Слабка типізація: Об'єкти мають типи, але неявно перетворюються на інші типи, коли цього вимагає контекст. Наприклад, Perl, PHP та JavaScript - це всі мови, на яких "1"можна використовувати більш-менш будь-який контекст 1.
• Сильне введення тексту: Об'єкти мають типи, і немає неявних перетворень (хоча перевантаження може використовуватися для їх моделювання), тому використання об'єкта в неправильному контексті є помилкою. У Python індексація масиву з рядком або float кидає виняток TypeError; в Haskell це не вдасться під час компіляції.

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

• Слабка типізація: Виконання недійсних операцій над даними не контролюється та не відхиляється, а лише дає недійсні / довільні результати.
• Сильне введення тексту: Операції над даними дозволяються лише у випадку, якщо дані сумісні з операцією.

Як я розумію, перша і остання характеристики називали б C слабо типованою, друга - назвала б сильно типізованою. Перші та другі називають Perl та PHP слабко типізованими, треті називають їх сильно набраними. Усі троє описують Python як сильно типізований.

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

Як пов'язане з цим питання, я вважаю, що динамічне / статичне розмежування часто дається у термінах "час компіляції" та "час запуску", що я вважаю незадовільним, враховуючи, що мова чи мова складена не стільки властивість цієї мови як його реалізації. Я вважаю, що має бути суто семантичний опис динамічної та статичної типізації; щось уздовж рядків "статична мова - це та, в якій може бути введено кожний підвираз". Буду вдячний за будь-які думки, зокрема посилання, які б пояснили це поняття.

Історично історично термін "сильно набрана мова програмування" вжив у 70-х роках у відповідь на існуючі широко використовувані мови програмування, більшість з яких мали отвори типу. Деякі приклади:

• У Fortran існували речі, які називаються областями зберігання "COMMON", які можна було б поділити між модулями, але не було перевірок, щоб кожен модуль декларував вміст сховища COMMON однаковими типами. Отже, один модуль міг оголосити, що певний блок зберігання COMMON мав ціле число, а інший - число з плаваючою точкою, і в результаті дані будуть пошкоджені. У Fortran також були заяви "EQUIVALENCE", згідно з якими одне і те ж сховище може бути оголошено таким, що містить два різних об'єкти різних типів.

• В Algol 60 тип параметрів процедури оголошувався як просто "процедура", не вказуючи типи параметрів процедури. Отже, можна припустити, що параметр процедури був процедурою, що приймає цілі числа, але передається в якості аргументу реально приймаючої процедури. Це призвело б до того ж виду корупції, що і твердження COMMON та EQUIVALENCE. (Однак Алгол 60 усунув старі проблеми.)

• У Паскалі були додані "варіанти записів", які були майже так само, як і колишні висловлювання EQUIVALENCE.

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

Сильно набрані мови, розроблені в 70-х роках, мали на меті усунути всі подібні отвори. Якщо вивчити, що це означає, це означає, що представлення даних захищено. Неможливо переглядати об'єкт даних одного типу як об'єкт іншого типу, який, мабуть, має такий самий бітовий зразок, що і його внутрішнє подання. Теоретики почали використовувати термін "незалежність представництва" для характеристики цієї властивості замість розпливчастої ідеї "сильного введення тексту".

Зауважте, що динамічно набрані мови, такі як Lisp, які виконують повну перевірку типу виконання, "сильно набираються" в сенсі захисту представлень. У той же час статично набрані мови втратять незалежність представництва, якщо вони не перевіряють межі масивів. Отже, вони не "сильно набрані" у строгому розумінні цього терміна. Через ці аномальні наслідки термін "сильно набраний" вийшов з ладу після 70-х років. Коли Міністерство оборони США розробило суворі вимоги до дизайну Ада, вони включили вимогу, що мова повинна бути "сильно набрана". (Схоже, в той час вважалося, що ідея "сильно набраного" була само собою зрозумілою. Жодного визначення не пропонувалося. ) Усі мовні пропозиції, подані у відповідь, стверджували, що вони "набрані". Коли Дайкстра проаналізував усі мовні пропозиції, він виявив, що жодна з них не була сильно набрана, і насправді навіть не було зрозуміло, що означає цей термін. Дивіться звітEWD663 . Однак я бачу, що цей термін повертається до вживання зараз через молоде покоління дослідників, які не знають картату історію цього терміна.

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

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

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

У статті Удай Редді, знайденій у своїй відповіді « Про розуміння типів, абстрагування даних та поліморфізм (1985), даються такі відповіді:

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

Авторитетні відповіді можна знайти у статті опитування Карделлі та Вегнера: Про розуміння типів, абстрагування даних та поліморфізм .

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