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


23

Вкратце: как системы типов классифицируются в академическом контексте; в частности, где я могу найти авторитетные источники, в которых четко различаются различные типы систем типов?

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

  • Нет типизации: язык не имеет представления о типах, или с точки зрения типизации: в языке есть только один тип. Язык ассемблера имеет только тип «битовый шаблон», Rexx и Tk имеют только тип «текст», ядро ​​MatLab имеет только тип «комплексная матрица».
  • Слабая типизация: существует только несколько выделенных типов и, возможно, синонимов типов для нескольких типов. Например, C использует целые числа для логических, целых чисел, символов, наборов битов и перечислений.
  • Строгая типизация: мелкозернистый набор типов, таких как языки ада, виртский язык (паскаль, модула-2), эйфелева

Это полностью противоречит моему личному восприятию, которое было больше похоже на:

  • Слабая типизация: объекты имеют типы, но неявно преобразуются в другие типы, когда этого требует контекст. Например, Perl, PHP и JavaScript - это все языки, на которых "1"можно использовать более или менее любой контекст, который 1может.
  • Строгая типизация: у объектов есть типы, и не существует неявных преобразований (хотя для их имитации может использоваться перегрузка), поэтому использование объекта в неправильном контексте является ошибкой. В Python индексирование массива со строкой или с плавающей точкой вызывает исключение TypeError; в Haskell это не удастся во время компиляции.

Я спросил мнение об этом у других людей, более опытных в этой области, чем я, и один из них дал такую ​​характеристику:

  • Слабая типизация: выполнение недопустимых операций с данными не контролируется и не отклоняется, а просто приводит к неверным / произвольным результатам.
  • Строгая типизация: операции над данными разрешены только в том случае, если данные совместимы с операцией.

Насколько я понимаю, первая и последняя характеристики будут называть C слабо типизированными, а вторая будет называть его строго типизированными. Первое и второе будут вызывать Perl и PHP со слабой типизацией, третье будет называть их строго типизированными. Все три описывают Python как строго типизированный.

Я думаю, что большинство людей скажут мне: «Ну, нет консенсуса, нет общепринятого значения терминов». Если эти люди не правы, я был бы рад услышать об этом, но если они правы, то как же исследователи CS описать и сравнить системы типов? Какую терминологию я могу использовать, что менее проблематично?

Как связанный вопрос, я чувствую, что динамическое / статическое различие часто дается в терминах «времени компиляции» и «времени выполнения», что я нахожу неудовлетворительным, учитывая, что то, является ли язык компилируемым, является не столько свойством этого языка как его реализации. Я чувствую, что должно быть чисто семантическое описание динамической и статической типизации; что-то вроде «статический язык - это язык, на котором можно напечатать каждое подвыражение». Я был бы признателен за любые мысли, особенно ссылки, которые вносят ясность в это понятие.


6
Я думаю, что у вас уже есть ответ: нет общепринятого определения слабой и сильной типизации.
svick

В это трудно поверить, но я задаю вопрос в надежде, что есть такой, о котором я просто не слышал :) или, по крайней мере, определение более авторитетное, чем то, что считает какой-то парень, который редактировал вики, ,
Бен Милвуд

3
Для более подробного обсуждения этого см. Этот связанный вопрос о SO .
svick

1
Чтобы подкрепить точку зрения Свика, невозможно найти авторитетную ссылку на то, что не принято. Все, что претендует на авторство, будет просто неверным (поскольку может быть предоставлено любое количество контрпримеров).
edA-qa mort-ora-y

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

Ответы:


18

Исторически термин «строго типизированный язык программирования» стал использоваться в 70-х годах как реакция на существующие широко используемые языки программирования, большинство из которых имели дыры в типах. Некоторые примеры:

  • В Фортране существовали вещи, называемые «ОБЩИЕ» области хранения, которые можно было разделять между модулями, но не было проверок, чтобы определить, объявлял ли каждый модуль содержимое хранилища COMMON одними и теми же типами. Таким образом, один модуль может объявить, что конкретный блок хранения COMMON имеет целое число, а другой - число с плавающей запятой, и в результате данные будут повреждены. У Fortran также были операторы «EQUIVALENCE», в результате чего одно и то же хранилище могло быть объявлено как содержащее два разных объекта разных типов.

  • В Algol 60 тип параметров процедуры был объявлен просто как «процедура», без указания типов параметров процедуры. Таким образом, можно предположить, что параметр процедуры является целочисленной процедурой, но в качестве аргумента передается реально принимающая процедура. Это приведет к тому же виду коррупции, что и заявления COMMON и EQUIVALENCE. (Тем не менее, Algol 60 действительно устранил старые проблемы.)

  • В Паскале были добавлены «вариантные записи», которые были почти такими же, как старые операторы EQUIVALENCE.

  • В C были добавлены «приведения типов», в результате чего любой тип данных мог быть интерпретирован как данные другого типа. Это была довольно преднамеренная дыра типа, предназначенная для программистов, которые предположительно знают, что они делают.

Строго типизированные языки, разработанные в 70-х годах, должны были устранить все подобные дыры. Если вы углубитесь в то, что это значит, это, по сути, означает, что представления данных защищены. Невозможно рассматривать объект данных одного типа как объект другого типа, который имеет тот же битовый шаблон, что и его внутреннее представление. Теоретики начали использовать термин «независимость представления» для характеристики этого свойства вместо смутной идеи «строгой типизации».

Обратите внимание, что динамически типизированные языки, такие как Lisp, которые выполняют полную проверку типов во время выполнения, «строго типизированы» в смысле защиты представлений. В то же время статически типизированные языки потеряли бы независимость представления, если бы они не проверяли границы массивов. Таким образом, они не являются «строго типизированными» в строгом смысле этого слова. Из-за этих аномальных последствий термин «строго типизированный» вышел из употребления после 70-х годов. Когда Министерство обороны США разработало строгие требования к дизайну Ады, они включали требование, чтобы язык был «строго типизирован». (Кажется, в то время считалось, что идея «строго типизированного» была самоочевидной. Никакого определения не предлагалось. ) Все языковые предложения, представленные в ответ, заявлены как «строго типизированные». Когда Дейкстра проанализировал все языковые предложения, он обнаружил, что ни одно из них не было строго напечатано и, на самом деле, даже не было ясно, что означает этот термин. Смотрите отчетEWD663 . Тем не менее, я вижу, что этот термин снова начинает использоваться благодаря молодому поколению исследователей, которые не знают изменчивой истории этого термина.

Термин «статически типизированный» означает, что вся проверка типов выполняется статически, и никаких ошибок типа во время выполнения не возникает. Если язык также строго типизирован, это означает, что в процессе выполнения ошибок типа нет . Если, с другой стороны, в системе типов есть дыры типов, отсутствие ошибок типов во время выполнения ничего не значит. Результаты могут быть полностью искажены.

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

Добавлено примечание : основной момент заключается в том, что термин «строгая типизация» не использовался в качестве технического термина со строгим определением. Это было больше похоже на то, что некоторые разработчики языка чувствовали: «наша система типов сильна; она ловит все ошибки типов; у нее нет дыр типов», и поэтому, когда они публиковали свой языковой дизайн, они утверждали, что она «строго типизирована» , Это было модное слово, которое звучало хорошо, и люди начали его использовать. Статья Карделли-Вегнера была первой, которую я видел, где был дан некоторый анализ того, что это значит. Мой пост здесь следует рассматривать как уточнение их позиции.


Можете ли вы дать некоторые ссылки на историческое развитие? «отсутствие ошибок типа во время выполнения ничего не значит» - вы имеете в виду время компиляции здесь?
Рафаэль

Вот статья о Евклиде, которая появилась в Google Scholar. Я помню, как видел несколько газет в 70-х годах, где утверждалось, что языки строго типизированы. Это обычно считалось коммерческим шагом.
Удай Редди

1
@Raphael. Я имел в виду "ошибки типа времени выполнения". Чтобы попасть во время выполнения, программе в первую очередь придется пройти проверку статического типа. Дело в том, что язык со строгой типизацией, например Java, будет выдавать ошибки типа во время выполнения, когда он не может их проверять во время компиляции. Язык дырок типа, например, C, позволит среде выполнения производить мусор вместо того, чтобы выдавать ошибки.
Удай Редди

1
@benmachine. См. Раздел «Проверка типов» в цитированной мной статье Евклида. Я думаю, что главное в том, что «строго типизированный» - модное слово. Это не техническое понятие. В лучшем случае, техническое содержание этого должно означать, что нет никаких типовых дыр.
Удай Редди

1
В типичной современной реализации, где два разных целочисленных типа имеют одинаковое представление (например, оба intи long32-битные, или оба longи long long64- разрядные), программа, которая использует указатель на один такой тип для записи некоторого хранилища и использует указатель другого типа читать его, как правило, не вызывает обнаруживаемую ошибку во время выполнения, но может произвольно работать со сбоями другими способами. Таким образом, современный C теряет безопасность типов, присутствующую в других языках, не получая семантики, которую имели качественные реализации языка Ричи. ранее предлагался в обмен.
Суперкат

7

Статья Удая Редди, найденная в его ответе « О понимании типов, абстракции данных и полиморфизме» (1985), дает следующие ответы:

Языки программирования, в которых тип каждого выражения может быть определен статическим анализом программы, называются статически типизированными. Статическая типизация является полезным свойством, но требование, чтобы все переменные и выражения были связаны с типом во время компиляции, иногда слишком ограничительно. Это может быть заменено более слабым требованием, чтобы все выражения гарантированно были согласованными по типу, хотя сам тип может быть статически неизвестным; обычно это можно сделать, введя некоторую проверку типов во время выполнения. Языки, в которых все выражения являются согласованными по типу, называются строго типизированными языками. Если язык строго типизирован, его компилятор может гарантировать, что программы, которые он принимает, будут выполняться без ошибок типа. В целом, мы должны стремиться к строгой типизации и использовать статическую типизацию, когда это возможно.


опубликовано как вики сообщества, так как я не заслуживаю признания за то, что нашел это.
Бен Милвуд

У меня есть проблема, связанная с первым комментарием svick. Хотя может быть неплохо, что вы нашли определение строгой типизации, это определенно не является общепринятым определением.
edA-qa mort-ora-y

@ edA-qamort-ora-y: на каком основании ты это говоришь? Есть ли у вас что-то лучше, чем анекдотические доказательства того, что является и не является общепринятым? Есть цитаты? (Я понимаю, что у вас может быть правильное мнение, даже если это не так, но я все же думаю, что вышеизложенное отвечает на мой вопрос; даже если нет единого мнения, было бы полезно знать хотя бы один из серьезных академических ответов).
Бен Милвуд,

1
Я не могу доказать отсутствие согласованного определения, могу ли я? Это логически невозможно. Тем не менее, статьи Википедии о строгой типизации действительно предоставляют много доказательств и ссылок для разногласий и противоречий. en.wikipedia.org/wiki/Strong_typing
edA-qa mort-ora-y

@ edA-qamort-ora-y: Цитаты из Википедии на самом деле не очень полезны: некоторые не являются академическими, другие цитируются по причинам, отличным от определения терминов. Документ «Типичное программирование» выглядит многообещающе, но лишь мимоходом обращается к определениям; возможно, в любом случае стоит отредактировать мой ответ. Что касается доказательства отсутствия, я думаю, что доказательства противоречия / разногласия среди людей, которые знают, о чем они говорят, мне было бы достаточно (что действительно может дать мне статья «Типовое программирование»).
Бен Милвуд

6

Авторитетные ответы можно найти в обзорной статье Карделли и Вегнера: « Понимание типов, абстракция данных и полиморфизм» .

Имейте в виду, что хотя «строгая типизация» имеет общепринятое значение, «слабая типизация» не имеет. Любой сбой строгой типизации может считаться слабым, и люди могут расходиться во мнениях о том, какой тип ошибки приемлем, а какой нет.



Отлично, это именно то, что я хотел. Документ требует небольшого прочтения, поэтому я думаю, что должен быть ответ, который суммирует основные моменты. Должен ли я отредактировать их в своем ответе или опубликовать свой собственный ответ вики? В любом случае, я собираюсь дать ему еще пару дней на случай, если кто-то еще что-то получит, а затем принять то, что осталось :)
Бен Милвуд,

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

4
Я все еще думаю, что это должно быть кратко изложено на этой странице. Срок действия ссылки может истечь позже.
Бен Милвуд

@benmachine. Вы можете опубликовать резюме в качестве собственного ответа на свой вопрос.
Удай Редди
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.