На этой странице обсуждения обсуждаются улучшения в статье о системе Type . Это не форум для общего обсуждения темы статьи. |
Политика статьи
|
Найти источники: Google ( книги · новости · газеты · ученый · бесплатные изображения · WP рефов ) · FENS · JSTOR · NYT · TWL |
Архивы : 1 , 2 |
|
Архивы бесед
- 2003–2006
- 2006–2009
Формулировка первоначального предложения
Я зашел на эту страницу, чтобы узнать о предмете, о котором я ничего не знаю. Вступительное предложение:
«В информатике система типов может быть определена как« управляемая синтаксическая структура для классификации фраз в соответствии с типами вычисляемых ими значений »».
Я этого не понял. Может быть, это было написано более простым языком? Mark.camp ( разговор ) 01:58, 27 декабря 2010 (UTC)
- Система типов языка программирования классифицирует выражения на этом языке (такие как переменные, арифметические выражения или функции) с точки зрения типов вычисляемых ими значений. Достаточно ясно? - FOo ( разговор ) 08:22, 27 декабря 2010 г. (UTC)
- Извините, все еще не ясно. Не могли бы вы выразить это на языке непрофессионала? Спасибо!
- Mark.camp ( разговор ) 00:50, 4 января 2011 (UTC)
- Это статья о технической концепции. Человек, который не знает, что такое «язык программирования», а также что такое «выражение», «переменная» или «функция», также не способен понять остальную часть статьи. Не все в мире можно выразить "языком непрофессионала" без потери точности или полезности.
- Система типов описывает вид значений (например, числа, строки, структуры данных), которые могут означать определенные выражения. Сюда входят литералы:
42
- целое число ;[1.3, 2.4, 3.5]
это список чисел с плавающей точкой ;"monkeybutt"
это строка . Но он также включает выражения, такие как арифметические выражения или функциональные приложения, например,40 + 2
будет вычисляться до целого числа ;concat("monkey", "butt")
будет оценивать строку и так далее. (Во всяком случае, на каком-то вымышленном языке.)
- Система типов описывает вид значений (например, числа, строки, структуры данных), которые могут означать определенные выражения. Сюда входят литералы:
- Это также позволяет нам говорить о типах, которые ожидаются как аргументы функции и которые возвращаются как результаты функции. Мы можем говорить о функции, которая принимает список целых чисел в качестве аргумента и возвращает целое число в качестве результата. ( Например, функция суммы .) Мы бы сказали, что сама сумма имеет тип: ее тип - это функция от списков целых чисел до целых чисел . (В Haskell мы бы записали этот тип как
[Int] -> Int
.)
- Это также позволяет нам говорить о типах, которые ожидаются как аргументы функции и которые возвращаются как результаты функции. Мы можем говорить о функции, которая принимает список целых чисел в качестве аргумента и возвращает целое число в качестве результата. ( Например, функция суммы .) Мы бы сказали, что сама сумма имеет тип: ее тип - это функция от списков целых чисел до целых чисел . (В Haskell мы бы записали этот тип как
- Что-нибудь из этого проясняет? Тем не менее, для меня все еще не очевидно, как это можно было сконденсировать в lede. Технические статьи будут техническими. - FOo ( разговор ) 04:31, 5 января 2011 г. (UTC)
- Спасибо, это именно то, что я искал. Можно ли включить часть этого текста в статью? Думаю, это сделало бы статью понятной для большего числа читателей.
- Mark.camp ( разговор ) 01:48, 11 января 2011 (UTC)
- Или, может быть, можно удалить те части статьи, которые прямо противоречат друг другу? Например: «Присвоение типов данных (типизация) придает значение последовательностям битов. Типы обычно связаны либо со значениями в памяти, либо с такими объектами, как переменные». Кетил ( разговор ) 13:15, 15 апреля 2011 (UTC)
- Шонхалле ( выступление ) 12:53, 10 декабря 2012 г. (UTC) Я пошел дальше и добавил вступление, которое должно быть понятным. Он дает значение системы типов, основные элементы системы типов и то, как эти элементы соотносятся с программой, компилятором и друг с другом.
- Основное описание многое относится к системе типов терминов. Некоторые из них принадлежат переводчику программы. Я считаю, что система типов - это концепция, не зависящая от языкового перевода. Конечно, это часть спецификации языка. Я не считаю, что это прямо применимо к выражениям. Тип выражений определяется его атомарными элементами и целевым использованием. Тип переменной, которой она назначена, или ее использование, например, индекс и т. Д. Выражения отношения, сравнивающие значения разных типов. Эти функции являются областью компилятора. Объекты данных могут нести свой тип, и комбинаторный тип должен определяться на лету. Просто немного неясно, что именно представляет собой система типов и где она подходит. Это во время языкового перевода. Часть спецификации языка. Неформально или формально?
- В статье говорится о типизации компиляторов и т. Д. Это все хорошо. Я и другие, которых я знаю, использую термин независимо от работы компилятора. Система типов языка определила его возможности. Мы можем сравнивать системы типов различных языков. В этом контексте система типов - это доступность, если типы реализованы и как их можно использовать в языке. Система типов языков определяет алгоритмы, которые могут быть выражены в языке. Эта статья посвящена реализации, которая, как мне кажется, является отдельной темой, принадлежащей symantecs.
- Steamerandy ( разговор ) 23:21, 27 февраля 2015 (UTC)
- Такая формулировка не совсем применима к функциональному языку, который является своего рода языком, который избегает алгоритмов до тех пор, пока не будет определена более фундаментальная семантика, чем алгоритмы. Термин «алгоритм» имеет императивную языковую историю, которая мешает. Нецелесообразно преждевременно отображать «алгоритм» до тех пор, пока не будут определены более фундаментальные объекты. Лучше сначала прочитать теорию типов . И лучше не использовать терминологию здесь в другом месте. Это сбивает с толку любое общение с людьми, изучавшими системы типов и теорию типов.
- Приношу свои извинения за то, что не согласился.
- Если вы говорите о компьютерных системах, таких как серия Берроуза или даже серия IPL , это действительно мир, отличный как с точки зрения точки зрения, так и по истории, от функциональных языков, обсуждаемых в статье.
- Но, судя по образцу кода Берроуза , это однопользовательские системы, чтобы не дать рекурсивным заданиям убить другие программы, которые также могут находиться в памяти. Правда? - Анчета Вис (обсуждение | вклад) 03:40, 28 февраля 2015 (UTC)
Эта страница обсуждения нуждается в архивировании
Старые и новые обсуждения слишком переплетены, чтобы за ними следовать. Pcap ping 09:57, 1 сентября 2009 г. (UTC)
- Я пошел дальше и заархивировал кучу разделов. Я надеюсь, что сейчас дела обстоят лучше. :) - pinkgothic ( обсуждение ) 21:30, 5 мая 2011 г. (UTC)
Удалить вводный тег
Вводный стиль, кажется, поправили? - AnAbsolutelyOriginalUsername42 ( обсуждение ) 19:41, 9 января 2010 г. (UTC)
- Текущее вступление действительно нужно переписать. Тег сказал, что это было недостаточно вводно, но ИМО кто-то переборщил, пытаясь исправить это. 66.127.55.192 ( разговорное ) 20:52, 2 февраля 2010 (UTC)
GADT
Я снял предложение
- Недавние усовершенствования языков со статической типизацией (например, обобщенные алгебраические типы данных Haskell ) позволили записывать функции eval со статической проверкой типов. [1]
что сбивает пример из статьи GADT с традиционным для Лиспа понятием функции eval, которая в основном является функцией типа (для всех a. String -> a). Пример в статье работает на уровне типизированного термина. Может, предложение как-нибудь переписать. 66.127.55.192 ( разговорное ) 19:13, 2 февраля 2010 (UTC)
Статья CACM
Следующая статья не очень хороша, но, возможно, в ней есть несколько полезных цитат:
http://cacm.acm.org/magazines/2010/2/69367-type-theory-comes-of-age/fulltext
66.127.55.192 ( разговорное ) 20:41, 2 февраля 2010 (UTC)
Go также является языком с динамической типизацией
Go - это не только статический тип, он также может использоваться как язык с динамической типизацией, и, конечно, вы можете написать следующее: var x = 12 x не типизирован и, следовательно, может принимать другой тип значения. x = "привет". —Предыдущий комментарий без подписи, добавленный 109.193.2.62 ( обсуждение ) 21:25, 28 мая 2010 г. (UTC)
Неразрешимая проблема?
Что означает это предложение?
«Безопасность типов способствует правильности программы, но не может гарантировать ее, если сама проверка типов не станет неразрешимой проблемой».
Если безопасность типов становится неразрешимой, не становится ли понятие утверждения правильности на основе безопасности типов явно недетерминированным (несмотря на ошибки времени выполнения)? Робертварви ( разговор ) 18:31, 24 июня 2010 (UTC)
- Это предложение означает, что когда система типов настолько мощна, что может отображать все желаемые свойства программы (например, завершение), тогда проверка типов становится неразрешимой, что означает, что будут программы, для которых средство проверки типов никогда не сможет опровергнуть свойство, даже если свойство не выполняется (например, что есть входы, для которых программа не завершается). Другими словами: если средство проверки типов должно для каждой программы по прошествии конечного времени либо доказать, что свойство выполняется, либо не выполняется, то вы должны либо ограничить рассматриваемые свойства, либо типы программ, разрешенных на вашем языке. Отвечает ли это на ваш вопрос? - Адрианон ( разговор ) 20:37, 24 июня 2010 г. (UTC)
- @Adrianwn: Я уверен, что да, но мне придется немного подумать, прежде чем я полностью это пойму. : P Навскидку, то, что вы описали, звучит как вариант проблемы остановки.
- Да, на самом деле проблема остановки - это причина, по которой никакая система разрешимых типов не может проверить завершение; если такая система предоставляет тип «итоговая функция с сигнатурой A -> B», тогда язык программирования должен будет наложить синтаксические ограничения на такие функции или отклонить некоторые функции, которые фактически являются итоговыми. Давайте посмотрим на другой пример:
P(x):
var a: array[0 ... 1000]; i := f(x); return a[i];
В общем случае система типов не может проверить, всегда ли доступ к массиву действителен (т. Е. Доказать, что 0 <= i <= 1000 для всех x), поскольку доказательство логики первого порядка является полуразрешимым. - Эдрианон ( разговор ) 06:58, 26 июня 2010 г. (UTC)
- Я не думаю, что этот аргумент верен. Операция
a[i]
действительна только для небольшого набора значенийi
. Таким образом, в строго типизированном языке это вызовет ошибку типа. Скажем ,f:: a -> Int
то онi := f(x)
имеет неправильный тип для доступа. - Предшествующий беззнаковый комментарий добавлен 129.138.26.151 ( обсуждение ) 23:13, 29 января 2015 г. (UTC)
Ассоциации; подтип; ∃X
- « Типы обычно связаны либо со значениями в памяти, либо с такими объектами, как переменные ».
- Что здесь подразумевается под ассоциациями ?
- « Программа обычно связывает каждое значение с одним конкретным типом (хотя тип может иметь более одного подтипа) ».
- Означает ли последнее утверждение, что тип всегда является подтипом самого себя?
- « Например, тип« T = ∃X {a: X; f: (X → int); } «описывает интерфейс модуля, который имеет член данных типа X и функцию, которая принимает параметр того же типа X и возвращает целое число ».
- Почему в этом выражении присутствует экзистенциальная количественная оценка "X"?
Спасибо, - Абдулл ( разговор ) 21:00, 8 сентября 2010 г. (UTC)
Утиная типизация - это неявная типизация?
Почему утиный тип объясняется в разделе о полиморфизме ? Если использовать объект в стиле утки, потому что он выглядит и крякает, как утка, я не возражаю, что это на самом деле. Это может быть не что иное, как обычная старая утка, поэтому никакого полиморфизма не требуется. Насколько я понимаю, утиная типизация гораздо больше связана с выводом типа : вывод типа используется во время компиляции, а утиная типизация используется во время выполнения. В обоих случаях программист заявляет, что он делает с объектом, и тип передается. - Якоб Восс ( разговор ) 08:39, 16 сентября 2010 г. (UTC)
- Согласно полиморфизму типов , «полиморфизм - это функция языка программирования, которая позволяет обрабатывать значения различных типов данных с использованием единого интерфейса» , что делает его похожим (по своим эффектам) на утиную типизацию. Однако я бы не сказал, что утиная типизация связана с выводом типа: никакой тип не должен / не должен вводиться во время выполнения. В конце концов, при утином вводе тип объекта не имеет значения, когда вызывается метод, имеет значение только то, предоставляет ли он запрошенный метод. - Адриан Вилленбюхер ( разговор ) 13:04, 16 сентября 2010 г. (UTC)
- Потому что статья тяготеет к динамически оспариваемым? Если вы хотите сгруппировать системы типов, тогда это станет лучшим из плохого набора групп, чтобы сделать его членом? (Гоша, я сегодня снайперский. Нормальное обслуживание будет возобновлено как можно скорее). - Пэдди ( разговор ) 13:11, 16 сентября 2010 г. (UTC)
- Я не уверен, что вы хотите выразить в первых двух предложениях. Вы имеете в виду, что в статье недостаточно представлены системы динамического типа? Что касается второго предложения, вы говорите, что раздел «утка» находится не в том месте? - Адриан Вилленбюхер ( разговор ) 17:48, 16 сентября 2010 г. (UTC)
- Я отвечу на некоторые вопросы, заданные Якобом выше. Говоря о утиной типизации и полиморфизме, в динамическом языке есть полиморфизм. Полиморфизм имеет дело с абстракцией, когда реализация метода изменяется для разных типов в системе. Я думаю, что, вероятно, возникает путаница в том, что не обязательно изменение типа интерфейса, как в Java, но вы можете иметь такое же поведение в Smalltalk (с динамической типизацией) без статической типизации. Рассмотрим объект Animal с методом «makenoise», который имеет простую реализацию (например, возврат «без шума»). Затем есть 2 подкласса Animal, Cat и Dog. Метод makenoise Dog возвращает «лай», а makenoise Cat возвращает «мяу. Вызов makenoise в списке животных превращается из Cat в Dog и т. Д., Даже при утином наборе текста. Существуют разные классы и, следовательно, разные типы. Что касается вывода типа. . Выведение типов может сбивать с толку, потому что на первый взгляд это очень похоже на динамическую типизацию. Большинство людей не помещают типы в объекты, поэтому это выглядит как утиная типизация. Вот разница. Выведение типа определяет во время компиляции, какой тип объекта основан на действиях (вызываемом методе) над этим объектом. Хороший пример различия: допустим, у нас есть специальный целочисленный тип (то есть класс MyInteger), который мы создаем, который имеет специальный метод addFrac. Случай вывода типа - легко, он видит addFrac во время компиляции, затем компилятор знает, что единственный объект, у которого есть метод addFrac, - это MyInteger. Это точно так же, как в Java, если бы вы специально объявили этот объект как тип MyInteger. Фактически, я бы сказал, в зависимости от на л anguage, может быть даже более строгим (вы все равно можете небезопасно преобразовать объект в другой тип в Java). Я думаю, что это иллюстрирует утиная типизация: допустим, вместо класса MyInteger у нас есть класс YourInteger, а у YourInteger нет метода addFrac. Ошибка компилятора отсутствует, потому что это динамический язык. Теперь, когда addFrac вызывается для экземпляра YourInteger, этот метод не существует, поэтому вызывается метод «поймать все». Скажем, мы определяем этот метод в YourInteger (я думаю, doesNotUnderstand в Smalltalk или method_missing в Ruby). Вызывается метод doesNotUnderstand, и, возможно, этот метод выполняет то же действие, что и addFrac. Итак, в этом примере на самом деле нет метода addFrac, но класс по-прежнему отвечает на вызовы addFrac (он крякает, как утка) с помощью метода catch all «doesNotUnderstand» - Райан Сеньор 23:35, 6 октября 2010 г. (CST) - Предыдущий беззнаковый комментарий, добавленный 99.183.215.173 ( обсуждение )
- Я бы подумал, что в вашем объяснении маловероятно, что метод doesNotUnderstand по умолчанию будет делать то, что вам нужно. Скорее всего, просто вызовет исключение. - Пэдди ( разговор ) 21:41, 8 октября 2010 г. (UTC)
B-класс? Как это случилось?
Есть ли какой-либо отчет или обсуждение классификации? Я думаю, что статья очень запутанная, и в ней есть много вещей, которые явно не так. Мне было бы интересно узнать, какие критерии использовались для получения этого рейтинга. Кетил ( разговор ) 13:10, 15 апреля 2011 (UTC)
ссылку на единую статью о слабой и сильной типизации ?
Есть избыточная информация о слабой типизации в системе типов и строгой типизации . На мой взгляд, система типов должна иметь краткое объяснение обоих (возможно, иметь таблицу примеров, доступную в настоящее время в сильной типизации ), а затем давать ссылку на статью, которая обрабатывает как слабую, так и сильную типизацию , поскольку объяснение каждого краткое, а концепции сравнивал каждый раз. Это должно упростить организацию этих знаний внутри Википедии. (Я пишу это мнение на всех трех текущих страницах обсуждения) - Roberto.cr ( обсуждение ) 09:13, 6 мая 2011 г. (UTC)
- Вы на самом деле отстаиваете статью со слабой типизацией или со строгой типизацией? - Пэдди ( разговор ) 14:46, 6 мая 2011 г. (UTC)
- На самом деле то же самое. Предмет действительно является осью сравнения, но я думаю, что «печатная сила» была бы неологизмом. - Кибер- кобра (разговор) 01:05, 7 мая 2011 г. (UTC)
Возможный плагиат в разделе о статической печати
Поскольку они оценивают информацию о типе во время компиляции и, следовательно, не имеют информации о типе, которая доступна только во время выполнения, средства проверки статического типа являются консервативными. Они отклонят некоторые программы, которые могут хорошо работать во время выполнения, но которые нельзя статически определить как хорошо типизированные. Например, даже если выражение <сложный тест> всегда оценивается как истинное во время выполнения, программа, содержащая код, if
будет отклонена как некорректно типизированная, поскольку статический анализ не может определить, что ветвь else не будет выполнена.
Кажется ужасно близким к тексту из первоисточника:
Будучи статичными, системы типов обязательно также консервативны: они могут категорически доказать отсутствие некоторых плохих программных действий, но они не могут доказать их присутствие, и, следовательно, они также должны иногда отклонять программы, которые действительно хорошо себя ведут во время выполнения. Например, такая программа if
будет отклонена как некорректно типизированная, даже если случается, что <комплексный тест> всегда будет оцениваться как истина, потому что статический анализ не может определить, что это так.
Danking00 ( разговор ) 16:24, 25 августа 2011 (UTC)
Система типов против проверки типов
Не смешиваются ли эти две идеи во введении без надобности? - Пэдди ( разговор ) 19:50, 29 октября 2011 г. (UTC)
- Более проблематично то, что в нем не проводится различие между теоретическим определением типов (формальная дедуктивная система, из которой обычно тривиально следует алгоритм проверки типов) и - более часто используемыми реальными программистами - определением, относящимся к особенностям языковой дисциплины типизации ( статическое против динамического, слабое против сильного, ...). - Рууд 12:17, 31 октября 2011 г. (UTC)
Пересечение типов функций
Из-за контравариантности я бы ожидал, что пересечение между int-> int и float-> float будет float-> int, а не каким-то различаемым объединением, как, кажется, подразумевается в статье.
Функцию типа float-> int можно безопасно использовать там, где ожидается функция типа int-> int (потому что при использовании она принимает введенные в нее целые числа), а также там, где функция типа float-> float является ожидал.
Есть ссылка на эту проблему? - Предыдущий неподписанный комментарий, добавленный Цвейджем ( обсуждение • вклад ) 18:52, 27 января 2012 г. (UTC)
- Вы говорите здесь о каком-то конкретном языке? Для меня это не имеет особого смысла, и я думаю, что это будет работать только с некоторым неявным преобразованием из чисел с плавающей точкой в целые числа. Кетил ( разговор ) 12:30, 9 марта 2012 (UTC)
Тарабарщина
Исходный код Wikitext в порядке, и история кажется нормальной, но когда я просматриваю статью, я вижу кучу тарабарщины . Тарабарщина (неудивительно) видна в исходном HTML. Что это за безумие? - Предыдущий неподписанный комментарий добавлен 63.249.90.205 ( обсуждение ) 16:44, 25 мая 2012 г. (UTC)
Последние изменения в разделе "Основы"
Раздел " Основы" был отредактирован практически полностью. Я пытался скопировать то, что там было, поверьте мне. Теперь он выложен по-другому, и при этом было переписано так много предложений и фраз. Я прошу вас просто прочитать это, чтобы понять, что я сделал. Я хочу разбить восемь абзацев на два подраздела, которые называются « Богатство развивается» и либо « Поддерживаются преимущества», либо « Поддерживаются преимущества», как показано в закомментированном викитексте. - Cp i r al Cpiral 02:13, 2 сентября 2012 г. (UTC)
Objective C также является динамическим языком
Как объясняется в статье википедии Objective C, Objective C, как и smalltalk, может использовать динамическую типизацию и считается динамическим языком. Так зачем использовать это как пример в разделе статической типизации? - Предыдущий беззнаковый комментарий добавлен 194.147.254.37 ( обсуждение ) 14:32, 5 ноября 2012 г. (UTC)
Система типов
Привет. Я не верю, что ваша недавняя система Type полностью точна. Смотрите мой комментарий, оставленный здесь . Не могли бы вы улучшить резюме и, возможно, немного расширить условия эксперимента? Особенно смотрите собственные выводы и описание автора в аннотации и в разделе «Выводы». Ура, - Рууд 11:49, 16 декабря 2012 г. (UTC)
- Вот что говорится в первом абзаце выводов: «во-первых: время разработки до внедрения минимального сканера… В первом случае использование статически типизированного языка программирования имело значительное негативное влияние». Удалите маленький тег или уточните предложение по своему усмотрению. Цитирование упомянутого предложения может сработать.
Что касается утиной печати, не упоминается: в исследовании сравнивается язык с динамической типизацией (естественно, с использованием утиной печати) со статически типизированным языком. Об исследовании нужно упомянуть где-нибудь на странице. Не стесняйтесь перемещать его. 46.14.124.168 ( разговорное ) 15:42, 16 декабря 2012 (UTC)
Безопасность типов и безопасность памяти
В этом примере z будет указывать на адрес памяти пятью символами после y, что эквивалентно трем символам после завершающего нулевого символа строки, на которую указывает y.
Разве не должно быть два ?
- Фолькер Александр ( разговор ) 12:10, 28 февраля 2014 г. (UTC)
- Нет, если y [] = "123456", y + 5 будет указывать на 6. QuentinUK ( разговор ) 16:50, 8 марта 2015 г. (UTC)
Предложение о слиянии
- Следующее обсуждение закрыто. Пожалуйста, не изменяйте его. Последующие комментарии следует делать в новом разделе. Краткое изложение сделанных выводов следует ниже.
- Результатом этого обсуждения не было слияния . - Dsimic ( Обсуждение | вклад ) 01:53, 23 декабря 2014 (UTC)
Постепенная типизация , как очень короткая статья, должна быть объединена в Систему типов § Объединение статической и динамической проверки типов . Он должен идеально подходить для этого, позволяя одновременно выполнять дедупликацию контента и более широкую картину. - Dsimic ( Обсуждение | вклад ) 00:43, 23 марта 2014 (UTC)
Если подумать, было бы гораздо лучше объединить его в новый раздел, Система типов § Постепенная типизация . Мысли? - Dsimic ( обсуждение | вклад ) 14:15, 24 марта 2014 (UTC)
- Не сливаться. Я согласен со второй мыслью и не поддерживаю слияние. Системный артикль типа уже такой длинный. Также, кажется, есть раздел, в который можно включить постепенную типизацию как подраздел: Type_system # Specialized_type_systems Я думаю, что уместно создать там подраздел для постепенного набора текста, поместить краткое описание постепенного набора текста, а затем одно из те основные шаблоны, которые направляют людей на статью « Постепенный набор текста» . - MadScientistX11 ( обсуждение ) 15:58, 8 августа 2014 г. (UTC)
Неясная поэтапность, пункт 2 раздела "Основы"
Я нахожу вступительное предложение второго абзаца раздела «Основы» несколько сбивающим с толку и неудобным для чтения.
В настоящее время он гласит:
Присвоение типа данных, так называемая типизация, придает смысл последовательностям битов, таким как значение в памяти или некоторый объект, такой как переменная.
Мое предлагаемое редактирование:
Акт присвоения типа данных, называемый типизацией, придает смысл последовательностям битов, таким как значение в памяти или некоторый объект, такой как переменная.
Есть возражения?
Bekroogle ( разговорное ) 07:47, 30 января 2015 (UTC)
- Здесь нет возражений. Но, честно говоря, хотя грамматически ваша версия IMO явно лучше, это не так много улучшений. Просто сказать «придает смысл» так банально. Я думаю, что лучшим улучшением (я не предлагаю эти точные слова, это просто не у меня в голове) было бы что-то вроде «предоставляет информацию программистам и системам, которые манипулируют программой, например компиляторам, которые определяют и ограничивают допустимые операции над последовательность битов, определяемых как данные ". Но в любом случае я согласен, что ваша версия определенно улучшена. - MadScientistX11 ( обсуждение ) 13:36, 30 января 2015 г. (UTC)
Новейшие встроенные теги
Решение новейших встроенных тегов потребует некоторой работы. Я перечисляю некоторые ресурсы, которые могут помочь нам исправить теги.
- Эволюция переполнения стека от строго типизированного (2009 г.) до строго типизированного (2014 г.)
- языки, которые компилируются в javascript
- Брайан Керниган (1981), Почему Паскаль не мой любимый язык программирования
- Джефф Этвуд, «Эффективное программирование: больше, чем написание кода»
- Жемчуг программирования Джона Бентли (2-е издание)
Одна из проблем заключается в том, что системы типов расширились, а технология вышла из употребления в отношении некоторых популярных языков. Возможно, будет более продуктивно переписать статью с точки зрения новых языков.
Здесь поможет вывод типа . - Анчета Вис (обсуждение | вклад) 15:14, 29 ноября 2015 (UTC)
Предложите лучший пример использования системы типов: приложение без указания URL
Предположим, мы ищем в Интернете дом для покупки: мы вводим критерии поиска в браузере и получаем список адресов, каждый из которых содержит URI дома, который соответствует нашим критериям.
Мы передаем список в приложение, программу на C. Но предположим, что программа C просто отображает строку байтов, не понимая, где конкретный тип, URI начинается / останавливается. Если приложение не понимает URI, пользователь этого приложения интуитивно будет знать, что в приложении что-то не так. Поэтому, если используется утилита с открытым исходным кодом, такая как http-parser.h , у приложения есть способ обрабатывать ошибки с точки зрения пользователя.
Теперь программа C имеет преимущество в декодировании остальных элементов в этом списке результатов поиска. Конечно, так же, как нам нужен код для синтаксического анализа URL-адресов, нам нужен код, который поможет нам начать обработку других типов, таких как изображения экстерьера, комнат в интерьере, виды улиц, озеленение, лужайка, подъездная дорожка, ванные комнаты, спальни, кухня. техника, окна и семейные комнаты. Нам нужен код, который обрабатывает типы для школ, безопасности района и так далее.
Я предлагаю внести исправления в эти операторы непосредственно перед простым примером C. - Анчета Вис (обсуждение | вклад) 02:34, 1 июля 2016 (UTC)
Разумность
Критика Реми выглядит как защита плохой печати. Сравните с лозунгом Милнера «хорошо напечатанные программы не могут ошибиться» Реми стр.7. Вместо того, чтобы зацикливаться на обсуждении разумности, возможно, мы могли бы рассмотреть другой подход; см. систему типов Хиндли-Милнера, используемую в Haskell. Кроме того, система типов Haskell отменена и теперь включает в себя непрерывность. - Анчета Вис (обсуждение | вклад) 01:46, 5 июля 2017 (UTC)
Этот вклад, похоже, касается нажатия клавиш пишущей машинки, а не систем набора текста.
Похоже, что концепция в этой статье касается стиля отступов, а не системы типов. - Анчета Вис (обсуждение | вклад) 15:08, 4 августа 2018 г. (UTC)
@ Stan0033 : Пожалуйста , см отступа стиль , правило вне игры , и пробельные статьи, которые уже охватывают свой вклад. Вместо того , чтобы печатать в том смысле , пробельные эта статья охватывает слово , используемое как в теории типов , тип данных , абстрактный тип данных , и его применение в системах типа - Ancheta ИСВ (ток | вклад) 19:27, 4 августа 2018 (UTC )
Фундаментальная путаница в отношении того, какие типы используются в программировании, а что такое статические и динамические типы.
Начнем с путаницы:
Эти типы формализуют и применяют неявные категории, которые программист использует для алгебраических типов данных.
Приведенное выше утверждение неверно в том смысле, что оно применимо только к группе языков программирования, но не ко всем. Легко увидеть, как это могло остаться незамеченным, поскольку языки программирования, популярные сегодня в индустрии, действительно хорошо вписывались бы в это описание. Однако важно также упомянуть, что изначально типы в программировании не воспринимались как формализация алгебраических типов данных (идея такой конструкции является гораздо более современной), а как инструкции по оптимизации для компиляторов, определяющих требования к хранилищу. Такова была позиция авторов АЛГОЛА, и, в значительной степени, это позиция многих языков, предшествовавших языкам семейства ML / Miranda.
Я также не понимаю, почему аннотации, такие как, например, режим создания экземпляров в языках семейства Prolog, будут обрабатываться иначе, чем типы (функционально они служат той же цели: для обеспечения правильности программы и, возможно, для подсказки компилятору об оптимизации. возможности). Это в то время как более распространенные языки, такие как, например, C, могут иметь множество модальностей, добавленных к определениям, указывающих, должна ли функция быть встроена, независимо от того, должна ли память, выделенная для структуры, быть дополнена нулями, чтобы быть кратным некоторому числу, должна ли функция реализовывать конкретное соглашение о вызовах и т. д. Точно так же Java и C ++ проверяют исключения и множество других подобных механизмов, которые все подпадают под категорию «обеспечения правильности программы путем предоставления дополнительной информации во время ее определения». Я не вижу причин, по которым их исключили бы из типовой семьи. Я думаю, необходимо указать, что «типы, как в теории типов, подполе математической логики = / = типы в программировании», однако, тесно связаны, особенно в контексте многих современных языков.
В итоге, я думаю, что процитированное утверждение (непреднамеренно) смещено в сторону конкретной интерпретации того, что означают типы, но оно недостаточно общее, чтобы должным образом отражать гораздо более разнообразную реальность.
Есть еще одна очень популярная путаница: языки со статической типизацией и языки с динамической типизацией. Многие люди верят, что эти вещи существуют, и регулярно используют эту терминологию. Однако нет реального определения, которое поддерживало бы такое разделение. Фактически, если вы последуете утверждениям людей, считающих, что конкретный язык является статически или динамически типизированным, вы легко обнаружите противоречие. Есть еще один способ интерпретировать, что означает «статический» и «динамический» применительно к типам. К сожалению, я не могу процитировать источник, но идея не моя: это делает его простым, однозначным и в то же время полезным. Статические типы - это типы, известные в любое время до выполнения программы (например, время компиляции или время проверки синтаксиса и т. Д.), А динамические типы - это типы, известные во время выполнения. Так, например, оператор в Java имеет вид List
Единицы измерения / размерный анализ как типы.
У меня есть неполная библиография на User: RDBrown / Prog Lang Dimensions on Units of Measure (Dimensional Analysis), добавляемых к языкам программирования. Тезис Гриффиоэна, основанный на работе Кеннеди и размерной линейной алгебре Харта, кажется современным для функциональных языков. Я не уверен, где краткое изложение некоторых из них должно быть в основной статье - должно ли это быть в одной из связанных статей? RDBrown ( обсуждение ) 04:37, 19 февраля 2020 г. (UTC)
Я добавил раздел «См. Также языки программирования» в « Анализ измерений» . RDBrown ( разговор ) 13:10, 30 марта 2020 (UTC)
- В Scientific method есть соответствующий поток : « Дональд М. Маккей проанализировал эти элементы с точки зрения пределов точности измерения и связал их с инструментальными элементами в категории измерения. [1] » - 09:20 , 19 февраля 2020 г. (UTC)
- Перечитывая цитату, «первая группа» (вычисляемая априори из спецификации) соответствует «типу». «Вторая группа» (рассчитанная апостериори из того, что было сделано ) соответствует «применению», как мы бы сказали сейчас. - 09:20, 19 февраля 2020 г. (UTC)
- Но теперь есть языки, в которых « оценка» отличается от «приложения». - 09:31, 19 февраля 2020 г. (UTC)
- Использование Гриффиоэном единицы в качестве модификатора выбранных величин в массиве (или, лучше, в кортеже) соответствует типу. - Анчета Вис (обсуждение | вклад) 09:41, 19 февраля 2020 г. (UTC)
Рекомендации
- ^ Научный метод требует апостериорного тестирования и подтверждения,прежде чем идеи будут приняты. «Неизменно приходилось сталкиваться с фундаментальными физическими ограничениями точности измерения ... Искусство физического измерения казалось вопросом компромисса, выбора между взаимно связанными неопределенностями ... Умножение вместе сопряженных пар упомянутых пределов неопределенности однако я обнаружил, что они образуют инвариантные продукты не одного, а двух различных видов ... Первая группа пределов вычислялась априори из спецификации прибора. Вторая группа могла быть вычислена только апостериори из спецификации что было сделано с инструментом ... В первом случае каждая единица [информации] добавляла бы одно дополнительное измерение (концептуальную категорию), тогда как во втором каждая единица добавляла бы один дополнительный элементарный факт », стр. 1–4 : Маккей, Дональд М. (1969), Информация, механизм и значение , Кембридж, Массачусетс: MIT Press, ISBN 0-262-63032-X
Орфография - «проверка типа»
Какое должно быть написание? Следующие?
- проверка типа (глагол)
- typechecking (имя существительное)
- проверка типов (прилагательное)
В Викисловаре есть только проверка типов (существительное).
- Мортенс ( разговор ) 21:54, 19 декабря 2020 г. (UTC)