Сильная и слабая типизация

Системы типов языков программирования

В компьютерном программировании один из многих способов классификации языков программирования заключается в том, делает ли система типов языка строго типизированным или слабо типизированным ( свободно типизированным ). Однако не существует точного технического определения того, что означают эти термины, и разные авторы расходятся во мнениях относительно подразумеваемого значения терминов и относительного рейтинга «силы» систем типов основных языков программирования. ^[1] По этой причине авторы, желающие однозначно писать о системах типов, часто избегают терминов «строгая типизация» и «слабая типизация» в пользу конкретных выражений, таких как « безопасность типов ».

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

Слабо типизированный язык имеет более слабые правила типизации и может давать непредсказуемые или даже ошибочные результаты или может выполнять неявное преобразование типов во время выполнения. ^[2] Другая, но родственная концепция — это скрытая типизация .

История

В 1974 году Барбара Лисков и Стивен Зиллес определили строго типизированный язык как язык, в котором «всякий раз, когда объект передается от вызывающей функции к вызываемой функции, его тип должен быть совместим с типом, объявленным в вызываемой функции». ^[3] В 1977 году К. Джексон писал: «В строго типизированном языке каждая область данных будет иметь отдельный тип, и каждый процесс будет формулировать свои требования к коммуникации в терминах этих типов». ^[4]

Определения слов «сильный» и «слабый».

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

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

Неявные преобразования типов и «каламбур типов»

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

Например, Ааз Марух отмечает, что « принуждение происходит, когда у вас есть статически типизированный язык и вы используете синтаксические особенности языка, чтобы принудительно использовать один тип, как если бы это был другой тип (рассмотрим обычное использование void* в C). ). С другой стороны, приведение обычно является признаком слабой типизации. Конверсия создает совершенно новый объект соответствующего типа». ^[5]

В качестве другого примера, GCC описывает это как игру слов и предупреждает, что это нарушит строгий псевдоним . Тьяго Масиейра обсуждает несколько проблем, которые могут возникнуть, когда каламбур типов приводит к тому, что компилятор выполняет неподходящую оптимизацию . ^[6]

Существует множество примеров языков, которые допускают неявное преобразование типов , но типобезопасным образом. Например, и C++ , и C# позволяют программам определять операторы для преобразования значения из одного типа в другой с четко определенной семантикой. Когда компилятор C++ встречает такое преобразование, он рассматривает эту операцию как вызов функции. Напротив, преобразование значения в тип C void* — небезопасная операция, невидимая для компилятора.

Указатели

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

Нетегированные союзы

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

Статическая проверка типов

В статье Луки Карделли «Типовое программирование» [ ^7] «система строгого типа» описывается как система, в которой нет возможности неконтролируемой ошибки типа во время выполнения. В других текстах отсутствие непроверенных ошибок во время выполнения называется безопасностью или безопасностью типов ; В ранних работах Тони Хоара это называется безопасностью собственности . ^[8]

Вариации между языками программирования

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

• Java , Pascal , Ada и C требуют, чтобы переменные имели объявленный тип, и поддерживали использование явного приведения арифметических значений к другим арифметическим типам. Иногда говорят, что Java, C#, Ada и Pascal более строго типизированы, чем C, поскольку C поддерживает больше видов неявных преобразований и позволяет явно приводить значения указателей , в то время как Java и Pascal этого не делают. Java можно считать более строго типизированной, чем Pascal, поскольку методы обхода системы статических типов в Java контролируются системой типов виртуальной машины Java . В этом отношении C# и VB.NET похожи на Java, хотя они позволяют отключать динамическую проверку типов путем явного помещения сегментов кода в «небезопасный контекст». Система типов Паскаля была описана как «слишком сильная», поскольку размер массива или строки является частью ее типа, что очень затрудняет некоторые задачи программирования. Однако Delphi решает эту проблему. ^{[9] [10]}
• Smalltalk , Ruby , Python и Self являются «строго типизированными» в том смысле, что ошибки ввода предотвращаются во время выполнения, и они мало выполняют неявное преобразование типов , но эти языки не используют статическую проверку типов: компилятор не проверяет и не обеспечивает принудительного выполнения типов. правила ограничения типов. Термин «утиная типизация» теперь используется для описания парадигмы динамической типизации, используемой языками этой группы.
• Все языки семейства Lisp являются «строго типизированными» в том смысле , что ошибки ввода предотвращаются во время выполнения. Некоторые диалекты Lisp, такие как Common Lisp или Clojure, поддерживают различные формы объявлений типов ^[11] , а некоторые компиляторы ( CMU Common Lisp (CMUCL) ^[12] и подобные) используют эти объявления вместе с выводом типа , чтобы обеспечить различные оптимизации и ограниченные формы компиляции. проверки типа времени.
• Стандартные ML , F# , OCaml , Haskell , Go и Rust проверяются статически, но компилятор автоматически определяет точный тип для большинства значений.
• Языки Ассемблер и Форт можно охарактеризовать как нетипизированные . Проверка типов отсутствует; Программист должен гарантировать, что данные, передаваемые функциям, имеют соответствующий тип.

Смотрите также

• Сравнение языков программирования
• Тип данных включает более подробное обсуждение проблем типизации.
• Проектирование по контракту (строгая типизация как неявная форма контракта)
• Скрытая типизация
• Безопасность памяти
• Тип безопасности
• Типовая система
• Строго типизированный идентификатор

Рекомендации

1. «Что нужно знать перед обсуждением систем типов | Овидий [blogs.perl.org]» . blogs.perl.org . Проверено 27 июня 2023 г.
2. «CS1130. Переход к объектно-ориентированному программированию. - Весна 2012 г. - версия для самостоятельного обучения». Корнелльский университет, факультет компьютерных наук. 2005. Архивировано из оригинала 23 ноября 2015 г. Проверено 23 ноября 2015 г.{{cite web}}: CS1 maint: bot: исходный статус URL неизвестен ( ссылка )
3. Лисков, Б; Зиллес, С (1974). «Программирование с абстрактными типами данных». Уведомления ACM SIGPLAN . 9 (4): 50–59. CiteSeerX 10.1.1.136.3043 . дои : 10.1145/942572.807045. 
4. Джексон, К. (1977). «Параллельная обработка и модульное построение программного обеспечения». Проектирование и реализация языков программирования . Конспекты лекций по информатике. Том. 54. С. 436–443. дои : 10.1007/BFb0021435. ISBN 3-540-08360-Х.
5. Ааз. «Ввод текста: сильный против слабого, статический против динамического» . Проверено 16 августа 2015 г.
6. "Каламбур типов и строгий псевдоним - Блог Qt" . Qt-блог . Проверено 18 февраля 2020 г. .
7. Лука Карделли, «Типовое программирование»
8. Хоар, CAR 1974. Советы по проектированию языков программирования. В книге «Надежность компьютерных систем» под ред. К. Буньян. Том. 20 стр. 505–534.
9. Инфомир. 25 апреля 1983 г. Проверено 16 августа 2015 г.
10. Керниган, Брайан (1981). «Почему Паскаль не мой любимый язык программирования». Архивировано из оригинала 6 апреля 2012 г. Проверено 22 октября 2011 г.
11. «CLHS: Глава 4» . Проверено 16 августа 2015 г.
12. «Руководство пользователя CMUCL: Компилятор» . Архивировано из оригинала 8 марта 2016 года . Проверено 16 августа 2015 г.