Type inference что означает
type inference
Смотреть что такое «type inference» в других словарях:
Type inference — Type inference, or implicit typing, refers to the ability to deduce automatically the type of a value in a programming language. It is a feature present in some strongly statically typed languages. It is often characteristic of but not limited to … Wikipedia
Type system — Type systems Type safety Inferred vs. Manifest Dynamic vs. Static Strong vs. Weak Nominal vs. Structural Dependent typing Duck typing Latent typing Linear typing Uniqueness typing … Wikipedia
Type polymorphism — In computer science, polymorphism is a programming language feature that allows values of different data types to be handled using a uniform interface. The concept of parametric polymorphism applies to both data types and functions. A function… … Wikipedia
Inference de types — Inférence de types L inférence de types est un mécanisme qui permet à un compilateur ou un interpréteur de rechercher automatiquement les types associés à des expressions, sans qu ils soient indiqués explicitement dans le code source. Il s agit… … Wikipédia en Français
Inférence De Types — L inférence de types est un mécanisme qui permet à un compilateur ou un interpréteur de rechercher automatiquement les types associés à des expressions, sans qu ils soient indiqués explicitement dans le code source. Il s agit pour le compilateur… … Wikipédia en Français
Type de données — Type (informatique) Pour les articles homonymes, voir Type (homonymie). En programmation un type de données, ou simplement type, définit le genre de contenu d une donnée et les opérations pouvant être effectuées sur la variable correspondante.… … Wikipédia en Français
Type recursif — Type récursif Dans un langage de programmation, un type récursif ou type inductif est un type de données pour des valeurs qui contiennent d autres valeurs du même type. Un exemple est le type liste en Haskell : data List a = Nil | Cons a… … Wikipédia en Français
Type III — may stand for:* Glycogen storage disease type III, a genetic disorder * Hyperlipproteinemia type III, a risk factor for cardiovascular disease * The IBM Type III Library, a distribution mechanism for unsupported IBM mainframe software such as… … Wikipedia
Inférence de types — L inférence de types est un mécanisme qui permet à un compilateur ou un interpréteur de rechercher automatiquement les types associés à des expressions, sans qu ils soient indiqués explicitement dans le code source. Il s agit pour le compilateur… … Wikipédia en Français
Type statique — Typage statique Sommaire 1 Définition 2 Langages à objets et typage statique 3 Problèmes 4 Résolution, autres difficultés … Wikipédia en Français
Inférence bayésienne — On nomme inférence bayésienne la démarche logique permettant de calculer ou réviser la probabilité d un événement. Cette démarche est régie en particulier par théorème de Bayes. Dans la perspective bayésienne, une probabilité n est pas… … Wikipédia en Français
Type Inference
Type inference is a Java compiler’s ability to look at each method invocation and corresponding declaration to determine the type argument (or arguments) that make the invocation applicable. The inference algorithm determines the types of the arguments and, if available, the type that the result is being assigned, or returned. Finally, the inference algorithm tries to find the most specific type that works with all of the arguments.
To illustrate this last point, in the following example, inference determines that the second argument being passed to the pick method is of type Serializable:
Type Inference and Generic Methods
The following is the output from this example:
Alternatively, if you omit the type witness,a Java compiler automatically infers (from the method’s arguments) that the type parameter is Integer :
Type Inference and Instantiation of Generic Classes
You can replace the type arguments required to invoke the constructor of a generic class with an empty set of type parameters ( <> ) as long as the compiler can infer the type arguments from the context. This pair of angle brackets is informally called the diamond.
For example, consider the following variable declaration:
You can substitute the parameterized type of the constructor with an empty set of type parameters (<>):
Note that to take advantage of type inference during generic class instantiation, you must use the diamond. In the following example, the compiler generates an unchecked conversion warning because the HashMap() constructor refers to the HashMap raw type, not the Map > type:
Type Inference and Generic Constructors of Generic and Non-Generic Classes
Note that constructors can be generic (in other words, declare their own formal type parameters) in both generic and non-generic classes. Consider the following example:
Consider the following instantiation of the class MyClass :
Compilers from releases prior to Java SE 7 are able to infer the actual type parameters of generic constructors, similar to generic methods. However, compilers in Java SE 7 and later can infer the actual type parameters of the generic class being instantiated if you use the diamond ( <> ). Consider the following example:
Target Types
Consider the following assignment statement:
However, this is not necessary in this context. It was necessary in other contexts, though. Consider the following method:
Suppose you want to invoke the method processStringList with an empty list. In Java SE 7, the following statement does not compile:
The Java SE 7 compiler generates an error message similar to the following:
Вывод типа
СОДЕРЖАНИЕ
Нетехническое объяснение [ править ]
Чтобы исключить нежелательное, но материально возможное использование, концепция типов определяется и применяется во многих вариантах. В математике парадокс Рассела породил первые версии теории типов. В языках программирования типичными примерами являются «ошибки типа», например, приказ компьютеру суммировать значения, которые не являются числами. Хотя это «материально» возможно, результат больше не будет значимым и, возможно, катастрофическим для всего процесса.
В общем, не только объекты, но и действия имеют типы и могут быть введены просто путем их использования. Для истории из «Звездного пути» таким неизвестным действием может быть «сияние», которое просто исполняется в целях развития сюжета и никогда официально не вводится. Тем не менее, по тому, что происходит, можно определить его тип (транспорт). Кроме того, как объекты, так и действия могут быть построены из их частей. В такой настройке вывод типа не только становится более сложным, но и более полезным, поскольку он позволяет собирать полное описание всего в составной сцене, сохраняя при этом возможность обнаруживать конфликтующие или непреднамеренные использования.
Проверка типов против вывода типов [ править ]
При типизации выражение E противопоставляется типу T, формально записанному как E: T. Обычно типизация имеет смысл только в некотором контексте, который здесь опускается.
В этой обстановке особый интерес представляют следующие вопросы:
Типы в языках программирования [ править ]
Однако в следующей строке result2 вычисляется путем добавления десятичной дроби 1.0 с арифметикой с плавающей запятой, что вызывает конфликт при использовании x как для целочисленных, так и для выражений с плавающей запятой. Правильный алгоритм вывода типов для такой ситуации известен с 1958 года и считается правильным с 1982 года. Он пересматривает предыдущие выводы и с самого начала использует наиболее общий тип: в данном случае с плавающей запятой. Однако это может иметь пагубные последствия, например, использование числа с плавающей запятой с самого начала может вызвать проблемы с точностью, которых не было бы при использовании целочисленного типа.
Однако часто используются вырожденные алгоритмы вывода типов, которые не могут выполнять возврат и вместо этого генерируют сообщение об ошибке в такой ситуации. Такое поведение может быть предпочтительным, поскольку вывод типа не всегда может быть нейтральным с алгоритмической точки зрения, как проиллюстрировано предыдущей проблемой точности с плавающей запятой.
Наконец, существенным недостатком сложного алгоритма вывода типов является то, что результирующее разрешение вывода типов не будет очевидным для людей (особенно из-за обратного отслеживания), что может быть вредным, поскольку код в первую очередь предназначен для понимания людей.
Недавнее появление своевременной компиляции позволяет использовать гибридные подходы, когда тип аргументов, предоставляемых различным контекстом вызова, известен во время компиляции, и может генерировать большое количество скомпилированных версий одной и той же функции. Затем каждую скомпилированную версию можно оптимизировать для другого набора типов. Например, JIT-компиляция позволяет использовать как минимум две скомпилированные версии add_one :
Версия, которая принимает целочисленный ввод и использует неявное преобразование типа. Версия, которая принимает на вход число с плавающей запятой и повсюду использует инструкции с плавающей запятой.
Техническое описание [ править ]
Чтобы получить информацию, необходимую для вывода типа выражения, компилятор либо собирает эту информацию в виде агрегата и последующего сокращения аннотаций типа, заданных для его подвыражений, либо посредством неявного понимания типа различных атомарных значений (например, истина: Bool; 42: целое число; 3,14159: вещественное число и т. Д.). Именно благодаря распознаванию возможного сокращения выражений до неявно типизированных атомарных значений компилятор языка с выводом типа может скомпилировать программу полностью без аннотаций типов.
В сложных формах программирования и полиморфизма высшего порядка компилятор не всегда может сделать такой вывод, и иногда для устранения неоднозначности необходимы аннотации типов. Например, известно, что определение типа с помощью полиморфной рекурсии неразрешимо. Кроме того, явные аннотации типов могут использоваться для оптимизации кода, заставляя компилятор использовать более конкретный (более быстрый / меньший) тип, чем он предполагал. [6]
Пример [ править ]
Например, функция Haskell map применяет функцию к каждому элементу списка и может быть определена как:
Алгоритм вывода типа Хиндли-Милнера [ править ]
Алгоритм, впервые использованный для выполнения вывода типов, теперь неофициально называется алгоритмом Хиндли-Милнера, хотя алгоритм следует правильно отнести к Дамасу и Милнеру. [9]
Побочные эффекты от использования наиболее общего типа [ править ]
По замыслу, вывод типа, особенно правильный (с возвратом), вводит использование наиболее подходящего типа, однако это может иметь последствия, поскольку более общие типы не всегда могут быть алгоритмически нейтральными, типичными случаями являются:
Вывод типа для естественных языков [ править ]
Алгоритмы вывода типов использовались для анализа естественных языков, а также языков программирования. [11] [12] [13] Алгоритмы вывода типов также используются в некоторых грамматических индукционных [14] [15] и основанных на ограничениях грамматических системах для естественных языков. [16]
СОДЕРЖАНИЕ
Нетехническое объяснение
Чтобы исключить нежелательное, но материально возможное использование, концепция типов определяется и применяется во многих вариантах. В математике парадокс Рассела породил первые версии теории типов. В языках программирования типичными примерами являются «ошибки типа», например, приказ компьютеру суммировать значения, которые не являются числами. Хотя это возможно с материальной точки зрения, результат больше не будет значимым и, возможно, пагубным для всего процесса.
В общем, не только объекты, но и действия имеют типы и могут быть введены просто путем их использования. Для истории из «Звездного пути» таким неизвестным действием может быть «сияние», которое просто выполняется в целях развития сюжета и никогда официально не вводится. Тем не менее, по тому, что происходит, можно определить его тип (транспорт). Кроме того, как объекты, так и действия могут быть построены из их частей. В такой настройке вывод типа не только становится более сложным, но и более полезным, поскольку он позволяет собирать полное описание всего в составной сцене, сохраняя при этом возможность обнаруживать конфликтующие или непреднамеренные использования.
Проверка типов против вывода типов
При типизации выражение E противопоставляется типу T, формально записанному как E: T. Обычно типизация имеет смысл только в некотором контексте, который здесь опускается.
В этой обстановке особый интерес представляют следующие вопросы:
Типы в языках программирования
Однако в следующей строке result2 вычисляется путем добавления десятичной дроби 1.0 с арифметикой с плавающей запятой, что вызывает конфликт при использовании x как для целочисленных, так и для выражений с плавающей запятой. Правильный алгоритм вывода типов для такой ситуации известен с 1958 года и считается правильным с 1982 года. Он пересматривает предыдущие выводы и с самого начала использует наиболее общий тип: в данном случае с плавающей точкой. Однако это может иметь пагубные последствия, например, использование числа с плавающей запятой с самого начала может вызвать проблемы с точностью, которых не было бы при использовании целочисленного типа.
Однако часто используются вырожденные алгоритмы вывода типов, которые не могут выполнять возврат и вместо этого генерируют сообщение об ошибке в такой ситуации. Такое поведение может быть предпочтительным, поскольку вывод типа не всегда может быть нейтральным с алгоритмической точки зрения, как проиллюстрировано предыдущей проблемой точности с плавающей запятой.
Наконец, существенным недостатком сложного алгоритма вывода типов является то, что результирующее разрешение вывода типов не будет очевидным для людей (особенно из-за обратного отслеживания), что может быть вредным, поскольку код в первую очередь предназначен для понимания людей.
Недавнее появление своевременной компиляции позволяет использовать гибридные подходы, когда тип аргументов, предоставляемых различным контекстом вызова, известен во время компиляции, и может генерировать большое количество скомпилированных версий одной и той же функции. Затем каждую скомпилированную версию можно оптимизировать для другого набора типов. Например, JIT-компиляция позволяет использовать как минимум две скомпилированные версии add_one :
Версия, которая принимает целочисленный ввод и использует неявное преобразование типа. Версия, которая принимает на вход число с плавающей запятой и повсюду использует инструкции с плавающей запятой.
Техническое описание
Чтобы получить информацию, необходимую для вывода типа выражения, компилятор либо собирает эту информацию в виде агрегата и последующего сокращения аннотаций типа, заданных для его подвыражений, либо посредством неявного понимания типа различных атомарных значений (например, истина: Bool; 42: целое число; 3,14159: вещественное число и т. Д.). Именно благодаря распознаванию возможного сокращения выражений до неявно типизированных атомарных значений компилятор языка с выводом типа может скомпилировать программу полностью без аннотаций типов.
В сложных формах программирования и полиморфизма высшего порядка компилятор не всегда может сделать такой вывод, и иногда для устранения неоднозначности необходимы аннотации типов. Например, известно, что вывод типа с полиморфной рекурсией неразрешим. Кроме того, явные аннотации типов могут использоваться для оптимизации кода, заставляя компилятор использовать более конкретный (более быстрый / меньший) тип, чем он предполагал.
Пример
Например, функция Haskell map применяет функцию к каждому элементу списка и может быть определена как:
Алгоритм вывода типа Хиндли-Милнера
Алгоритм, впервые использованный для выполнения вывода типов, теперь неофициально называется алгоритмом Хиндли-Милнера, хотя этот алгоритм следует правильно отнести к Дамасу и Милнеру.
Побочные эффекты от использования самого общего типа
По замыслу, вывод типа, особенно правильный (с возвратом), вводит использование наиболее подходящего общего типа, однако это может иметь последствия, поскольку более общие типы не всегда могут быть алгоритмически нейтральными, типичными случаями являются:
Вывод типов для естественных языков
Алгоритмы вывода типов использовались для анализа естественных языков, а также языков программирования. Алгоритмы вывода типов также используются в некоторых грамматических системах индукции и грамматики на основе ограничений для естественных языков.
Var и val в Java?
От переводчика: автор этой заметки — Stephen Colebourne, автор библиотеки Joda Time и Java Time API.
Следует ли добавить вывод типов локальных переменных в Java? Как раз сейчас команда разработчиков языка Java задалась этим вопросом.
Вывод типов локальных переменных
JEP-286 предлагает добавить вывод типов локальных переменных, используя новое псевдоключевое слово (интерпретируемое как «зарезервированное наименование типа»):
Явное указание типа локальных переменных зачастую не является необходимым. Разрешив разработчикам опускать его, мы хотим упростить разработку на Java, уменьшив необходимое количество формальностей, но при этом не жертвуя статической типизацией.
Предлагается несколько вариантов ключевых слов:
Несмотря на вышесказанное, я подозреваю, что шансов остановить реализацию этого улучшения у меня немного. Поэтому оставшаяся часть статьи посвящена тому, как выбрать правильный вариант из предложенных.
Наилучший вариант для Java
Главная причина того, что наилучший вариант для Java может быть другим, — это история. В Скале и Котлине эта возможность была с самого начала, а в Java — нет. И я хочу продемонстрировать, почему из-за исторических причин использование val или let не подходит для Java.
Рассмотрим следующий код:
Вывод типов локальных переменных прекрасно бы здесь сработал. Но предположим, что тип переменной в одной из строчек неясен при чтении кода и мы решили указать его явно, следуя рекомендациям C#:
(Возможно, вы не используете final для каждой локальной переменной? Я вот не использую. Но я знаю, что это вполне разумный стандарт, придуманный для улучшения безопасности разработки и уменьшения ошибок.)
А вот альтернативный вариант:
Я понимаю, какие возражения возникнут у многих читателей в этом месте. Мол, должно быть два новых «ключевых слова», одно для изменяемых и одно для неизменяемых локальных переменных и оба должны быть одинаковой длины (или даже слово для изменяемых должно быть длиннее), чтобы подталкивать людей чаще использовать неизменяемую версию.
Но в Java не всё так просто. Слово final существует многие годы. Если закрыть глаза на этот факт, код превратится в некрасивое и непоследовательное месиво.
Вывод
Мне лично вывод типов локальных переменных не нравится вообще. Но если мы всё-таки решили его делать, надо, чтобы он хорошо вписывался в существующий язык.
Моя позиция заключается в том, что val и let не подходят для Java, потому что уже существует слово final и оно имеет вполне понятный смысл. Хотя вариант с var и final var не идеален, я считаю, что это единственная из предложенных комбинаций, которая подходит уже существующему языку.