Talk:Безопасность типов

Требуется очистка

Я пришел на эту страницу, пытаясь узнать о Type Safety. Я прочитал в первом абзаце, что существуют разные определения этого термина, но мне не сказали, какие именно. Я продолжаю читать, но так и не узнаю, что такое Type Safety.

Поэтому я заглянул в Определения, думая, что найду какие-нибудь подсказки. Но определение начинается с милой маленькой цитаты, которая на самом деле ничего мне не говорит (и, кстати, очевидно, не является правдой). Поэтому я продолжаю читать и обнаруживаю, что там есть определения, но определения для Type Safety. Даже определение 'Type' было бы хорошо, но увы, нет.

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

Определение Type Safety в статье "Strongly-typed programming language" гораздо яснее, чем содержание этой статьи. Очистка определенно требуется

То, что вы говорите, правда. Проблема в том, что не существует общепринятого определения этого термина или даже набора свойств, которые программа может иметь, чтобы считаться типобезопасной. Например, см. обсуждение сборки мусора ниже. Статья написана с идеализированной теоретической точки зрения (что является ключом к тому факту, что безопасность в типобезопасности не имеет большого отношения к безопасности реальной жизни, хотя я уверен, что теоретики не согласятся). Дерек Фарн

Спасибо за отзыв. Не пытаясь создать «идеальное» определение того, что такое безопасность типов, можно ли дать нечеткое определение. Например, можно ли перечислить особенности безопасности типов, с которыми согласны все определения? А затем перейти к перечислению различий между определениями. Что-то вроде: «Некоторые определения безопасности типов включают a).. ​​b)... c)... , тогда как другие считают, что для безопасности типов действительно требуются только d)... и e)...». Таким образом, не будет проблемы с попыткой создать определение, с которым все согласятся, потому что, как вы говорите, это может быть невозможно. Но, по крайней мере, я смогу получить простую идею заранее, которая заставит меня подумать: «Ага, теперь я понимаю, о чем статья, я могу решить, нужно ли мне читать дальше или нет». Если бы это было возможно, я думаю, это во многом помогло бы статье.

«Формальное определение типобезопасности в теории типов значительно сильнее того, что понимает большинство программистов». Кто подсчитал, сколько программистов понимают типобезопасность и каким образом? Эта фраза не несет никакой новой или даже интересной информации, кроме как является оценочной. Перефразировать или удалить? Похоже, она подразумевает, что существует распространенная путаница (не нужно указывать процент программистов, которые запутались, достаточно двух программистов, разделяющих путаницу, чтобы путаница стала распространенной), что типобезопасность — это атрибут среды, исполняющей программу, а не языка (что, по сути, и было сказано в предыдущем предложении.) — Предыдущий неподписанный комментарий добавлен 109.65.38.7 (обсуждение) 11:27, 28 апреля 2012 (UTC) [ ответить ]

Сбор мусора и безопасность типов

Обычно языку необходимо иметь сборку мусора, чтобы быть типобезопасным.

Так ли это? Я не думаю, что gc имеет какое-либо отношение к безопасности типов. Безопасность типов, как описано в datatype , заключается в том, что правила типов жестко соблюдаются. Например, вы не можете выполнить сложение целых чисел над значением с символьным типом данных, хотя это, возможно, возможно на уровне базовой компьютерной архитектуры. -- Taku 23:13, 17 апреля 2004 г. (UTC)

GC не требуется для безопасности типов. Вы можете создать язык без какого-либо освобождения памяти, и он все равно будет типобезопасным. Программы будут просто иметь тенденцию исчерпывать память быстрее, чем в противном случае, что неприятно, но и не является типобезопасным. Более практично, есть альтернативные схемы управления памятью, такие как управление на основе регионов, которые обеспечивают типобезопасность. Я думаю, тот, кто упомянул GC, предполагал, что GC — единственная альтернатива malloc/free в стиле C (или new/delete в C++), хотя на самом деле альтернатив много. —Предыдущий комментарий без знака добавлен 204.14.239.222 (обсуждение) 17:02, 5 апреля 2011 (UTC)[ отвечать ]

Ну, если вы прочтете статью, gc имеет массу общего с безопасностью типов. Если у вас нет gc, вы, возможно, можете изменить указатель на что угодно. Путаница заключается в том, что люди используют термин безопасность типов по-разному. Это часть цели статьи. MShonle 23:16, 17 апреля 2004 (UTC)

Упс, я думал о строгой типизации. Хорошо, а что насчет умного указателя ? Разве он не гарантирует, что указатель не сломан? -- Taku 23:29, 17 апреля 2004 г. (UTC)

В статье GC умные указатели перечислены как форма сборки мусора. Однако у подсчета ссылок есть недостаток, заключающийся в том, что циклически связанный список может оказаться «мертвым»: недостижимым, но все равно выделенным. У подсчета ссылок есть некоторые преимущества перед пометкой и очисткой, но он все равно может привести к утечкам памяти. Гибридная форма подсчета ссылок плюс пометка и очистка, вероятно, не будет такой быстрой, как современный сборщик мусора. MShonle 23:59, 17 апреля 2004 (UTC)

Почему кто-то может изменить указатель на что угодно, если нет gc? Glass Tomato 09:20, 2 ноября 2007 (UTC) [ ответить ]

Потому что обычно, когда в языке есть сборка мусора, это подразумевает, что нет прямого манипулирования указателями в коде, и что встроенная в язык сборка мусора обрабатывает все это. Когда в языке нет автоматической сборки мусора, например, в C, вы должны вручную управлять выделением и освобождением указателей в памяти в коде. В C единственная информация, которую вам нужно предоставить функции выделения памяти, — это сколько байтов требуется для типа, на который ссылается указатель, X, а затем функция возвращает первый адрес памяти, выделенный для типа X, который затем приводится к указателю типа X и назначается переменной. Однако опасность здесь заключается в том, что вы потенциально можете назначить количество байтов выше или ниже того, что требуется для типа X, что приведет к пустой трате памяти, если выше, и неопределенному поведению, если ниже. Одним из возможных результатов является ошибка сегментации ; другой заключается в том, что после назначения недостаточного объема памяти одному указателю вы назначаете память другому указателю, но поскольку программа управления считает, что хвостовая часть памяти, требуемой для типа первого указателя, свободна, она выделяет следующий указатель, начиная с первого «свободного» адреса после. Итак, теперь у нас есть два указателя на переменные с перекрывающимися блоками памяти, и изменение одного может изменить другой. Это те виды проблем, которые автоматическая сборка мусора пытается устранить, что, я считаю, является ключом к пониманию ее связи с безопасностью типов. WastedMeerkat ( talk ) 06:27, 8 мая 2014 (UTC) [ ответить ]

Зачем объединять? Типы данных и безопасность типов — разные темы. Могу ли я предложить обсуждение безопасности типов данных разместить здесь? На этой странице следует обсудить безопасность типов, как в этой книге [1]

Извините, я не думал достаточно внимательно. Я увидел статью, внезапно появившуюся без контекста datatype, поэтому я подумал, что это результат вклада участника, который не знает о статье datatype . Думаю, я не уверен в этой теме. Мое понимание типобезопасности — это просто безопасность, описанная в статье datatype . Из прочтения статьи следует, что тема отличается от системы типов, делающей язык безопасным. -- Taku 23:29, 17 апреля 2004 г. (UTC)

Спасибо, я думаю, что ссылка на datatype — хорошая идея. Я также включил в datatype ссылку сюда. Жаль, что «безопасность типов» может относиться как к строгой типизации, так и к «полной семантике». В академических кругах мы используем безопасность типов только в математическом смысле (можно сказать, что Scheme была строго типизирована, но у нее был только один тип (например, «объект»). В отрасли, похоже, больше придерживаются другого определения. Не то чтобы одно использование было «неправильным», но в литературе полезно знать, что существует различие. MShonle 23:39, 17 апреля 2004 (UTC)

Полная семантическая модель?

Некоторые вопросы:

Язык C мог бы стать типобезопасным, если бы имел полную семантическую модель. Например, если бы код C был переведен в код Scheme вместе с моделью для моделирования машины, то это определение C было бы типобезопасным при условии, что вся семантика была бы полной. В C вы можете изменить значения указателей на что угодно, но это можно смоделировать с помощью модели системы памяти, состоящей из массивов Scheme.

Самое запутанное в этом утверждении то, что возникает реальный вопрос, будет ли C + полная семантическая модель на самом деле все еще C. —Предыдущий неподписанный комментарий добавлен 204.14.239.222 (обсуждение) 17:04, 5 апреля 2011 (UTC)[ отвечать ]

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

В любом случае, что такое полная семантическая модель? Из прочитанного следует, что в C отсутствует семантический режим, в то время как в Java и Scheme, поэтому C не является типобезопасным, а Java и Scheme — да. Это просто означает, что в C есть способ обойти систему типов? А как насчет C++? Он такой же небезопасный, как C? -- Taku 23:41, 17 апреля 2004 г. (UTC)

Полная семантическая модель может сказать вам что-то вроде «при данной программе и этих входных данных, и если я запущу ее на такое количество шагов, каково будет значение всего?» Семантика может начинаться с правил редукции в стиле лямбда-исчисления. Чтобы доказать типобезопасность Java, была «легкая Java-модель», которая давала бы вам редукции в стиле L-исчисления. Но если у меня есть программа на C, она может изменить любую память, которая ей нужна, что иногда может непредсказуемым образом изменить все поведение программы.

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

C++ также небезопасен, потому что вы можете изменять указатели. Вам пришлось бы удалить арифметику указателей и прочее из C++, а также добавить сборку мусора, чтобы хотя бы начать делать его безопасным. (Это, по сути, дает вам нечто более близкое к Java.) Чтобы не показалось, что я ругаю C++, я упоминаю C. Я также добавил ту маленькую часть о том, что C используется для написания gc, чтобы быть уверенным, что C тоже не ругают. MShonle 23:55, 17 апреля 2004 (UTC)

Большое спасибо. Теперь статья стала для меня гораздо более понятной. Сейчас я пытаюсь сделать ее более доступной. Пожалуйста, не стесняйтесь исправлять любые мои ошибки, включая грамматические. -- Taku 00:14, 18 апреля 2004 г. (UTC)

Я сделал несколько небольших правок. MShonle 00:21, 18 апреля 2004 (UTC)

Почему вы удалили это [2]? Я думал, это поможет понять, что имеется в виду под ошибками, делающими систему типов Java небезопасной. -- Taku 00:22, 18 апреля 2004 г. (UTC)

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

Тип безопасности/типы

Может быть, это просто плохой термин, но я нахожу идею "безопасности типов", которая, по-видимому, не имеет ничего общего с типами, довольно подозрительной. Это какая-то историческая случайность?

Деррик Кутзее 17:01, 18 апреля 2004 (UTC)

Судя по всему, статья относится к теории типов , а не к типу данных . В контексте типа данных , действительно не имеет смысла, что Scheme является типобезопасным, будучи слабо типизированным. Но я провел небольшое исследование. Статья в конце концов является допустимой темой. Я думаю, что мы должны подчеркнуть больше аспектов доказательства программ в статье. Не принято (ну, для большинства из нас) доказывать, что язык является математически типобезопасным. Я также подозреваю, что это как-то связано с кодом, несущим доказательства, или чем-то подобным. В любом случае, я не в теме и у меня нет книг или формальных ресурсов, чтобы много рассказать. MShonle кажется знающим. Так что, может быть, мы просто можем доверять ему?

В любом случае, правда, нам нужно добавить больше контекстов. Без фоновых знаний, я не думаю, что статья имеет много смысла, как gc гарантирует типобезопасность. Это, вероятно, правда, но статья должна более четко сформулировать, почему и как. -- Taku 17:10, 18 апреля 2004 (UTC)

Дкутзее и Такуя: я посещал занятия для аспирантов у одного из выдающихся исследователей безопасности и надежности типов, так что это не та тема, которая поднимается даже у типичного аспиранта по информатике.

Существует связь с типами, в которой вы не хотите, каким бы то ни было образом, изменять биты фрагмента данных, не разрешенные языком. (Ну, в случае с C изменение битов разрешено, но поведение не определено.) Маттиас Феллейзен позже сказал, что, возможно, его работу следовало бы назвать «полной спецификацией» вместо безопасности типов, но, ну, никто ее так не называет.

В любом случае, есть проницательный фрагмент человеческого знания, когда вы понимаете, что сбор мусора необходим для безопасности, и поэтому достоин записи в энциклопедии. MShonle 20:37, 18 апреля 2004 (UTC)

На самом деле, GC не является необходимым для типобезопасности; GC — это всего лишь один из механизмов, обеспечивающих типобезопасное распределение памяти. Например, управление памятью на основе регионов обычно не рассматривается как сборка мусора, но (при соответствующей поддержке системы типов) является типобезопасным. k.lee 07:14, 18 авг. 2004 (UTC)

Это хороший момент. Возможно, это можно сформулировать как "сборка мусора или другие ограниченные системы управления памятью (т. е. те системы памяти без висячих указателей, или где висячие указатели могут указывать только на объекты того же типа)". В любом случае, суть в том, что люди, которые устанавливают правила о строгом приведении типов (и т. д.), которые думают, что у них есть язык программирования с безопасной типизацией, просто обманывают себя, если у них нет GC или они предвидели его с помощью какой-то другой формы ограниченного управления памятью. MShonle 19:20, 8 мая 2005 (UTC) [ ответить ]

Сомнительные заявления

Эта статья полна весьма сомнительных заявлений (Java и Scheme были «математически доказаны» как типобезопасные? Для типобезопасности требуется сборщик мусора?). В ней даже не упоминаются ключевые концепции типобезопасности, а именно сохранение типов и прогресс! Я призываю редакторов прочитать проливающее свет обсуждение этой самой темы в списке TYPES. Данная статья только демонстрирует ненужную путаницу семантики (типы) и деталей реализации (gc и т. д.). — Kaustuv 20:06, 2004 17 августа (UTC)

Обратите внимание, что в своем текущем состоянии статья обсуждает сохранение и прогресс, почти в самом верху статьи. Другие читатели также должны увидеть беседу с Каустувом и мной ниже, которая объясняет, почему GC — это больше, чем просто деталь реализации. (Справедливости ради, я бы назвал это технической деталью, так же как в математическом доказательстве деление на ноль является «технической деталью», которая может быть достаточно существенной, чтобы сделать доказательство недействительным.) --MShonle 02:34, 8 января 2006 (UTC) [ ответить ]

Другое сомнительное утверждение: «C++ более типобезопасен, чем C, если используется правильно (избегая использования указателей void и приведения между указателями двух типов)». Давняя традиция языков типа C, делающих неявные приведения между int и char*, по своей сути небезопасна для кода типа «int x = 123456 ; std::string s ("hello") ; s += x ;». Ни один известный мне компилятор не выдаст предупреждение на этой строке. Взять это целое число и неявно привести его к char*, чтобы его можно было объединить с std::string, просто неправильно. Это так же неправильно, как и «strcat (s, 1233456)» в C, но, по крайней мере, версии на C выглядят неправильно. — Предыдущий комментарий без знака добавлен 150.101.204.108 (обсуждение) 00:51, 21 января 2011 (UTC) [ ответить ]

Путаница в сборе мусора

Фраза «обычно требуется» — это чистая скользкая формулировка. Либо GC необходим в типобезопасном языке, либо нет. Если это всего лишь один из способов реализации типобезопасности, то связь такова, что в некоторых типобезопасных языках нет GC, а в некоторых нетипобезопасных языках есть GC. Я думаю, это можно квалифицировать как нерелевантное.

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

Я думаю, что это ход мыслей: безопасность типов не работает с арифметикой указателей (см. пример). Отсутствие арифметики указателей «обычно» подразумевает сборку мусора. Отсюда и связь. Но вы правы, это не строгое утверждение. Вы можете представить себе язык, который типобезопасен, но не имеет сборщика мусора. Черт, представьте себе язык типобезопасности без динамической памяти! Wouter Lievens 19:11, 7 мая 2005 (UTC) [ ответить ]

Очень сложно для общего языка быть типобезопасным и не иметь GC. Я попытаюсь объяснить эту концепцию здесь: предположим, что в вашем языке нет GC. Тогда это означало бы, что у вас могут быть так называемые висячие указатели. Теперь предположим, что у вас есть висячий указатель на объект, который имеет целочисленное поле. Теперь предположим, что новый объект выделяется поверх того места, где раньше было это целочисленное поле, но вместо целочисленного поля это указатель. Если вы теперь возьмете висячий указатель и измените целочисленное поле, вы фактически произвольно измените значение указателя!

Язык без GC мог бы обойти эту проблему, только разрешив размещать объекты одного типа только в одних и тех же местах. Подсчет ссылок также можно использовать, но подсчет ссылок на самом деле считается техникой GC... но это уже совсем другая тема. MShonle 22:14, 7 мая 2005 (UTC) [ ответить ]

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

Можете ли вы привести цитаты для этого утверждения, что безопасность типов требует сборки мусора? Возможно, в книге Пирса? — Kaustuv 22:27, 2005 May 13 (UTC)

Да, это в Pierce. У меня нет моей копии здесь, но вы, вероятно, можете найти ее, посмотрев сборку мусора в индексе. Besdies, разве я уже не привел достаточно причин? Рассуждения вышли из моды? В любом случае, вот целая статья, которая предполагает тему: Безопасность памяти без проверок во время выполнения или сборка мусора. Обратите внимание, что результат статьи был рассмотрен в статье, сказав «или специализированное управление памятью». В любом случае, это совершенно нетривиально, и для понимания безопасности и типобезопасности жизненно важно понимать, что введение типизации и избегание всех приведений все еще может привести к проблемам (если вы не используете GC, как Java, C#, Scheme, ML, Smalltalk... или другие трюки). MShonle 22:57, 13 мая 2005 (UTC) [ ответить ]

В упомянутой вами статье говорится о безопасности памяти , которая, как я бы сказал, сильно отличается от безопасности типов . Первое — это, по сути, деталь реализации, а второе — семантическая деталь. Я предполагаю, что вы не предлагаете считать их одной и той же проблемой. (Обратите внимание, что выход за пределы массивов возможен даже в языках с безопасностью типов, таких как SML.) Я жду вашей конкретной цитаты из Пирса, где обосновано утверждение, что «безопасность типов требует сборки мусора (или специализированного управления памятью)». Номера страниц будут уместны. — Kaustuv 23:10, 2005 May 13 (UTC)

Почему слова Пирса о том, что 2+2=4, более верны, чем мои слова? Думаю, я полностью продемонстрировал вам, что сборка мусора является важным элементом типобезопасности. Обратите внимание, что когда вы выходите за пределы массива, если вы получаете исключение, это совершенно нормально: семантика говорит, что происходит, когда выбрасывается исключение. Что *не* нормально, так это то, что семантика C никогда не говорит, что происходит, когда вы перезаписываете массив. То, что происходит, может повлиять даже на то, какой код будет выполнен следующим. Никто никогда не должен утверждать, что C — типобезопасный язык: называть его небезопасным — это не оценочное суждение о самом C. Я уже ясно дал понять в статье, что сборщики мусора лучше всего писать на таких языках, как C (и Пирс говорит о том же).

(Кстати, только что прочитал введение к статье. Они делают те же заявления, что и я. Только *после* этого они говорят о безопасности памяти.)

Если вы не понимаете проблему висящего указателя, вам следует задать мне вопросы (здесь, на странице обсуждения), и мы попытаемся разобраться. Если вы считаете, что неопределенное поведение (такое как отнесение числа с плавающей точкой) все еще может быть типобезопасным, то это совершенно отдельная тема для обсуждения. Если вы просто хотите услышать, как Пирс это скажет, ну, подождите, пока я вернусь домой к книге, и, возможно, мы перестанем тратить время на споры о том, кто сказал, что 2+2=4. MShonle 23:22, 13 мая 2005 (UTC) [ ответить ]

Вот долгожданная цитата Пирса из его книги «Типы и языки программирования», 2002 г., стр. 158:

«Последняя проблема, которую мы должны упомянуть, прежде чем перейти к формализации ссылок, — это выделение памяти . Мы не предоставили никаких примитивов для освобождения ячеек ссылок, когда они больше не нужны. Вместо этого, как и во многих современных языках (включая ML и Java), мы полагаемся на систему выполнения для выполнения сборки мусора , сбора и повторного использования ячеек, которые больше не могут быть доступны программе. Это не просто вопрос вкуса в разработке языка: чрезвычайно сложно добиться безопасности типов при наличии явной операции освобождения. Причиной этого является знакомая проблема висячих ссылок : мы выделяем ячейку, содержащую число, сохраняем ссылку на нее в некоторой структуре данных, используем ее некоторое время, затем освобождаем ее и выделяем новую ячейку, содержащую логическое значение, возможно, повторно используя то же хранилище. Теперь у нас может быть два имени для одной и той же ячейки хранилища — одно с типом Ref Nat, а другое с типом Ref Bool».

MShonnele 01:31, 14 мая 2005 (UTC) [ ответить ]

У меня уже был комментарий здесь, но потом я понял, что это мусор. Спасибо за ссылку. — Kaustuv 01:50, 2005 May 14 (UTC)

Просто для уверенности: безопасность типов заключается в том, что программы «не ошибаются». То, что я описал здесь, — это способ, которым, даже если вы не можете манипулировать битами указателя напрямую (как это позволяет приведение типов в C), вы все равно можете заставить программу «взорваться» с помощью этого сложного примера с висячим указателем, который я описал. Чтобы обойти эту проблему с висячим указателем, вы можете использовать либо сборку мусора (обычно), либо пулы выделения объектов, где только структурно эквивалентные объекты выделяются в тех же областях памяти (используется редко). Если вы не попадаете ни в GC, ни в это (относительно) редкое управление, язык не является типобезопасным. MShonle 21:59, 13 мая 2005 (UTC) [ ответить ]

Я перефразировал обсуждение GC и безопасности типов. Утверждение, что безопасность типов требует GC, строго говоря, неверно, IMHO. Рассмотрим гипотетический язык, который запрещает псевдонимы указателей (так что назначение одного указателя другому будет глубоким копированием, а не поверхностным). Или язык, в котором при освобождении выделения все указатели на освобожденное хранилище устанавливаются на нулевой указатель. Оба языка не используют GC, и хотя их практическая ценность сомнительна, они также не страдают от конкретной проблемы безопасности типов, описанной в статье.

Хотя мы можем бесконечно спорить о проблеме GC, я думаю, что более важным моментом является то, что статья не должна фокусироваться на этом вопросе в первую очередь. Статья должна обсуждать вопрос «какие виды операций мы можем разрешить в типобезопасном языке?» Как выясняется, одним из видов операций, которые необходимо запретить, являются некоторые комбинации типичных типов «указателей» и ручного управления памятью. Эти ограничения должны быть в центре обсуждения — вопрос о том, как следует реализовать управление ресурсами в языке без этих свойств, является второстепенным (поэтому его следует упомянуть мимоходом, как это делает моя редакция статьи). Другими словами, статья должна говорить о семантике языка; GC — это деталь реализации. Neilc 14:12, 14 мая 2005 (UTC) [ ответить ]

На самом деле, мы не говорим, что безопасность типов требует GC. Мы говорим, что она требует GC или какого-то другого героического управления памятью . Вы доказываете это своими двумя альтернативными примерами (вы предлагаете что-то столь же сложное, как операция пометки; и ваше предложение о глубоком копировании кажется непрактичным). Я думаю, что крайне важно, чтобы статья затрагивала проблему GC, по одной причине, это совершенно не интуитивно, но это то, что должен знать каждый исследователь систем типов. Также, пожалуйста, ознакомьтесь с цитатой Пирса, примерно тремя абзацами выше этого сообщения. Он один из выдающихся исследователей в этой области, и я поверю ему на слово, как и Википедия. MShonle 18:00, 14 мая 2005 (UTC) [ ответить ]

Да, я не говорю, что нам не нужно упоминать GC, я говорю, что акцент в статье был неправильным, и он так же неправильный в вашей обновленной версии. Я сделал некоторые изменения, которые, как я думаю, улучшают это. Что касается "GC лучше всего реализован в языках с арифметикой указателей", это, похоже, не имеет отношения к статье, поэтому я снова удалил это. Neilc 00:55, 15 мая 2005 (UTC) [ ответить ]

Замечание о реализации не не имеет значения. Оно служит трем целям, возможно, больше: (1) оно возвращает связь, что у вас могут быть безопасные программы в языках, не являющихся безопасными по типу; (2) оно показывает, что для создания систем, не являющихся безопасными по типу, вам могут понадобиться небезопасные функции; и, таким образом, (3) статья занимает нейтральную позицию по отношению к программистам на языке C. Многие могли бы прочитать статью и подумать, что она критикует C, когда на самом деле там говорится: «Чтобы реализовать системы с этими свойствами, о которых мы говорим, нам нужно что-то вроде C».

Что касается вашего мнения об акцентах статьи, возможно, вы сможете привести какие-то доводы, кроме того, что вы говорите, что считаете это "неправильным". Я уже ответил на ваши другие опасения. Более того, в статье нет ничего фактически неправильного, так как я недавно ее в основном редактировал. Я также собираюсь изменить некоторые ваши формулировки, которые испортили смысл. MShonle 01:51, 15 мая 2005 (UTC) [ ответить ]

Как моя формулировка "разрушила" "смысл"? Что касается того, что я считаю "неправильным", я уже объяснил свои доводы относительно того, на чем должен быть акцент статьи; прочитайте мой первый комментарий. Вы так и не ответили на эту часть моего комментария, поэтому я не стал повторяться. В любом случае, я достаточно доволен текущим состоянием статьи; я по-прежнему не согласен, что примечание о реализации GC стоит включить, но это не так уж важно. Neilc 02:21, 15 мая 2005 (UTC) [ ответить ]

Я рад, что мы достигли консенсуса, потому что я устал от людей, читающих эту правдивую, обоснованную, логичную и интересную заметку о сборке мусора и пытающихся отвергнуть ее как не соответствующую действительности. Я чувствовал, что ваше вводное предложение испортило смысл, сказав «наложить ограничения на ... ручное управление памятью». Для меня это уже не ручное управление памятью, когда это GC (квалификатор «ручной» испортил смысл). Поэтому я изменил его на «ограничения на выделение и освобождение памяти». Вы можете иметь GC, который определенно делает это (со стороны освобождения), или выделение на основе региона (со стороны выделения). Извините за использование сильных слов, таких как «испорчен», но я был весьма зол на вас, когда вы сказали, что статья «неправильная», когда она говорила чистую правду, и вы просто не согласились со стилем, в котором она была представлена. MShonle 02:41, 15 мая 2005 (UTC) [ ответить ]

Требование утилизации памяти (сборка мусора или что-то еще) является полностью прагматичным и не имеет ничего общего с семантикой. Вы могли бы прекрасно определить язык, который имеет ограниченные требования к памяти (требуя массивы фиксированного размера, никаких указателей и никакой рекурсии, даже косвенной — и да, такие языки существуют), или который дает сбой, когда у него заканчивается память (самая чистая семантика не может предотвратить этого в общем случае...). Формулировку нужно изменить, чтобы отразить все это. -- Macrakis 00:36, 27 января 2006 (UTC) [ ответить ]

Новый раздел «Определения»

Первоначально я просто хотел добавить ссылку на Райта и Феллейзена, которым обычно приписывают изобретение Сохранения и Прогресса. В итоге я создал новый раздел Определения и забеспокоился о том, что статья определила надежность типа таким образом, чтобы полностью исключить денотационно-определенные языки (в них нет ничего аналогичного Прогрессу). Статья W&F описывает некоторые из основанных на денотационно-семантических понятиях безопасности, которые существовали до того, как они сделали свое дело; похоже, что пока эта статья будет упоминать формальные вещи, мы должны по крайней мере оставить место для того, кто знает о денотационно-семантической семантике, чтобы вставить пару слов, поэтому я попытался это сделать.

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

Еще одна вещь, которую, как мне кажется, эта статья должна была бы сказать, но не сказала: только в типобезопасном языке аннотации типов действительно имеют смысл. В языке C вы можете объявить локальную переменную

struct something *x;

но, поскольку C не является типобезопасным, вы никогда не можете быть уверены, что xуказывает на легитимный объект something, если только вы только что не создали его сами. В Java, с другой стороны, если вы говорите

Somethingх;

то все, что может привести к xчему-либо иному, чем экземпляр Something(или один из его подклассов), будет незаконным.

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

Cjoev 00:04, 24 января 2006 (UTC) [ ответить ]

Теория против практики.

Хотя я и являюсь ярым сторонником типобезопасности, мне кажется, что статья слишком сильно посвящена теоретической стороне вопроса.

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

Так что чем больше я читаю обсуждение здесь, тем больше мне интересно, может ли какой-либо "реальный" язык программирования на самом деле архивировать "безопасность типов", как описано здесь. Это если они не откажутся от возможности быть самостоятельным хостингом :

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

На самом деле большинство языков, упомянутых здесь как тип save, не являются самостоятельными .

Это напоминает мне «Почему Pascal не мой любимый язык программирования» — особенно главу 2.6. «Нет выхода». Вопрос: Разрешено ли языку сохранения типов иметь выход? Пример: Я всегда считал, что Ada — это язык сохранения типов — и действительно: поведение Ada по умолчанию следует двум правилам, изложенным в этом модуле. Однако в Ada есть выходы в виде Unchecked_conversion и Unchecked_Deallocation (и некоторых других).

-- Крищик  ^Т 10:18, 25 января 2006 г. (UTC) [ ответ ]

Зависит от того, что вы подразумеваете под «выходом». Если попытки выхода проверяются во время выполнения и терпят неудачу, если они не имеют смысла (как, например, приведения в Java), то язык может быть типобезопасным. Если выход возможен способами, которые не имеют смысла, без того, чтобы реализация языка это заметила, то это означает, что язык не является типобезопасным. Я немного не понимаю семантику конструкций Ada, о которых вы упомянули, но тот факт, что они называются «непроверенными», определенно предполагает, что они нарушают типобезопасность, делая утверждение, что «Ada ... [была] показана типобезопасной», крайне подозрительным, если не сказать больше.

Ну, в Ada есть случай [[grep]инга для "Unchecked_Deallocation", "Unchecked_Convertion" и "Unchecked_Access". Если ни один из них не был использован, то система типов не была нарушена и, как таковая, сохранена. Ada служит двойной цели: проектировщики хотели язык с сохранением типов, который также подходил бы для программирования встроенных систем . Но похоже, что системное программирование и безопасность типов действительно являются взаимоисключающими.

Ada поставляется с двумя преобразованиями. Проверенное преобразование, как в Java (даже имеет тот же синтаксис в стиле функций) и Unchecked_Convertion, которое является универсальным/шаблонным.

Если на то пошло, я не думаю, что Pascal (классический «типобезопасный язык», который все ненавидели из-за его ограничений) действительно типобезопасен — если я правильно помню, по крайней мере классический язык Pascal старых времен не был таковым из-за проблемы с вариантными записями. Я не знаю о более современных диалектах Pascal.

Действительно верно. В отличие от Ады, Паскаль не проверял вариант на допустимость. Во времена Паскаля я часто использовал запись варианта для выполнения "Unchecked_Convertion". -- Krischik  ^T 07:24, 26 января 2006 (UTC) [ ответить ]

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

Думаю, мне нужно подумать об этом некоторое время. -- Krischik  ^T 07:24, 26 января 2006 (UTC) [ ответить ]

Кстати, я думаю, можно с уверенностью сказать, что ни один из многих языков безопасности типов, используемых сегодня, не может быть самохостинговым. Однако большинство из них делают bootstrap и пытаются ограничить использование небезопасных языков сборщиком мусора, системными библиотеками и как можно меньшим количеством других частей системы выполнения, с которыми они могут справиться.

Я тоже так думал. И, принимая во внимание строгое правило, я не думаю, что это когда-либо будет возможно. -- Krischik  ^T 07:24, 26 января 2006 (UTC) [ ответить ]

Cjoev 20:57, 25 января 2006 (UTC) [ ответить ]

Krischik, надеюсь, ты не будешь возражать, но я реорганизовал твой последний вклад. Надеюсь, я сохранил твое намерение, если не твой язык. Я думаю, что наша беседа показала, что когда дело доходит до оценки реальных языков и реализаций, существует большая серая зона между C (действительно очень небезопасным) и чем-то, что удовлетворяет формальному определению до последней буквы. Исходя из этого, я думаю, что вместо того, чтобы просто перечислять языки, которые попадают в различные категории, может быть разумнее обсудить проблемы, связанные с различными языками. Это то, что я пытался сделать (и добавил немного о моем любимом языке). Я думаю, что этот список может расти: например, Java имеет довольно большую историю ошибок безопасности типов, которые были обнаружены и исправлены. Большинство из них связаны с загрузчиками классов и прочим. Надеюсь, кто-то знающий сможет это заполнить.

Cjoev 01:22, 27 января 2006 (UTC) [ ответить ]

Молодец - я думаю, что твой подход лучше моего - ты ставишь проблемы на первое место. -- Krischik  ^T 07:12, 27 января 2006 (UTC) [ ответить ]

Я только что подумал о другом моменте. Вы много раз говорили, что "поведение по умолчанию" Ады является типобезопасным. Я бы сказал наоборот: "По умолчанию" компиляторы Ады позволяют вам использовать типобезопасные функции, когда вы захотите. Поэтому, при отсутствии некоторых гарантий обратного (например, тех, которые вы можете получить при поиске кода), любая данная программа Ады должна считаться небезопасной . Другими словами, если мне представлена ​​двоичная форма сторонней библиотеки, написанной на Аде, и у меня нет доступа к исходному коду, я не могу просто предположить, что ее авторы не использовали никаких непроверенных функций! Я думаю, что вы имеете в виду, и что я пытался выразить, так это то, что типобезопасное программирование должно быть поведением по умолчанию программистов Ады в том смысле, что использование небезопасных конструкций должно быть редким.

Cjoev 22:31, 26 января 2006 (UTC) [ ответить ]

Действительно верно. Я начал обсуждение некоторых вопросов, затронутых в [3]. Эта статья заставила меня задуматься о некоторых вопросах. -- Krischik  ^T 07:12, 27 января 2006 (UTC) [ ответить ]

Безопасность типов Java

Правда ли, что Java считается типобезопасным? Мне кажется, вы можете поместить объект любого класса в контейнер, а затем извлечь его как любой другой класс. При первой попытке доступа к любому члену ваша программа падает! Если вы считаете, что типобезопасность — это ваше определение термина, отличное от моего. — Предыдущий неподписанный комментарий был добавлен 209.4.89.67 ( talk • contribs ) 22:35, 26 января 2006 (UTC)

Нет, программа не падает. Она вызывает исключение. Формально говоря, есть большая разница: исключения, тот факт, что вы можете их перехватывать и обрабатывать, и тот факт, что они возникают в определенных ситуациях, являются частью спецификации языка и, следовательно, полностью предсказуемы. Вы даже можете представить себе программиста, полагающегося на это исключение, чтобы обнаружить определенное совершенно нормальное состояние в программе (но вы надеетесь, что на самом деле никто этого не делает). Напротив, когда приведение типа C++ идет не так, вы не замечаете этого сразу, но конечный результат зависит от реализации, то есть находится за пределами спецификации языка. Это может быть иное определение, чем ваше, но это настоящее определение.

Cjoev 01:03, 27 января 2006 (UTC) [ ответить ]

Java теперь (считается) типобезопасной. Сарасват указал на ошибку в ранних версиях Java, которая была исправлена ​​введением ограничений загрузки для предотвращения подмены типов. Подробности см. в статье ([4]) Ляна и Брачи с OOPSLA'98. Glyn normington 15:51, 12 октября 2007 (UTC) [ ответить ]

Кроме того, проблема, выявленная в статье OOPSLA, не была недостатком Java (языка), который соответствует определению типобезопасности. Недостаток был в реализации конкретной виртуальной машины Java (в данном случае JVM 1.1 от Sun). Хотя это и заслуживает внимания, он давно был исправлен, и на странице делается неверное неявное утверждение, что проблема была в Java, а не в JVM. Я собираюсь исправить страницу, чтобы отметить проблему, но удалить вывод о том, что Java не является типобезопасной. trims2u 21:20, 19 июня 2011 UTC — Предыдущий неподписанный комментарий добавлен 98.210.108.64 (обсуждение)

Вырожденная система типов?

Предположим для целей обсуждения, что определенная реализация определенного языка имеет некоторый тип, скажем , такой, что существует некоторая последовательность битов (соответствующей длины), которая не является законным членом . (Все, кроме самых вырожденных систем типов, удовлетворяют этому критерию.) ${\displaystyle t}$ ${\displaystyle t}$

Эм, какая последовательность битов недопустима в среднем типе int, float или pointer? Являются ли системы типов, в которых есть только несколько действительно базовых типов, вырожденными? Например, в C есть только целые (включая char), с плавающей точкой, массивы и указатели, не так ли? Любая последовательность битов соответствующей длины будет допустимой для любого из них, если только я чего-то не упускаю. (Ну, нулевой указатель обычно указывает на проблему, но это все еще допустимое значение, я должен думать.) — Simetrical ( talk  •  contribs ) 16:44, 19 мая 2006 (UTC) [ ответить ]

Я это написал. Возможно, «вырожденный» — не совсем подходящее слово; «тривиальный» может быть лучше. Обратите внимание, что в примере требуется только один тип во всем языке, который не является членом. Int и float не подходят, но является ли последовательность бит допустимым значением указателя, если она указывает на недоступную память? Может ли значение быть указателем на функцию, если оно не указывает на код? Возможно, в C, но не в языках, которые удовлетворяют более строгим понятиям безопасности типов или безопасности памяти. В этом смысле, да, я бы сказал, что система типов C тривиальна и/или вырождена. Конечно, любая система для «классификации» значений вырождена, если она не отличает одно от другого? Cjoev 22:30, 21 мая 2006 (UTC) [ ответить ]

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

Как я уже признал, это верно для C , но это верно не для всех языков. Если вы проникнете в память работающей программы Java и замените содержимое переменной ссылочного типа (массив или объект) случайными битами, вы, скорее всего, внесете ошибку такого рода, которая в противном случае не могла бы возникнуть. С другой стороны, если вы сделаете это с программой C, конечно, вы, вероятно, ее уничтожите, но не таким образом, который язык мог бы когда-либо исключить. Основываясь на этом, я утверждаю, что написанные вами биты не являются допустимым значением для переменной Java, поскольку их размещение там может привести к тому, что программа будет вести себя совсем не так, как это свойственно Java, хотя вы могли бы сказать, что они являются допустимым значением для переменной C, поскольку вы не нарушили никаких свойств безопасности языка, вводя их. Cjoev

Видите ли, дело в том, что классификация значений в C различает разные типы одинакового размера. Указатели обычно имеют ту же длину, что и int, по крайней мере, на данный момент, но синтаксически они обрабатываются по-разному: например, попытка установить целое число в строку приведет к ошибке компилятора, тогда как установка указателя равным строке совершенно допустима. Разница в том, что различие проводится на уровне компилятора, а не на уровне машины: компилятор отловит неправильную типизацию, но как только вы сведете себя к ассемблеру, фактические битовые шаблоны будут идентичны.

Итак, по сути: учитывая, что любая система типов, запрещающая определенным типам (заданной длины) содержать определенные битовые комбинации, всегда может быть переформулирована (часто более эффективно) с помощью простого отображения таким образом, чтобы все битовые комбинации были допустимы, я не думаю, что реализация типов языка на машинном уровне является особенно веской причиной объявлять ее вырожденной или нет, или даже тривиальной или нет. — Simetrical ( обсуждение  •  вклад ) 02:59, 24 мая 2006 (UTC) [ ответ ]

Туше. Я признаю, что рассмотрение машинной реализации — плохой способ судить о языках. Обычно я всем это говорю. Но: (1) параграф, с которого началось это обсуждение, был о связи между безопасностью типов и безопасностью памяти, а последнее — это вопрос реализации (я думаю, это упоминалось в обсуждении намного выше на этой странице), поэтому осмысленное обсуждение должно говорить о реализации; и (2) мы должны говорить о любом языке на уровне, на котором определяется его семантика. C, если я не ошибаюсь, определен в терминах его реализации на машине; поэтому невозможно что-либо сказать о его системе типов, не ссылаясь на биты и вещи.

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

В итоге, вы не согласны с моим аргументом о том, что безопасность типов и безопасность памяти связаны, или вы не согласны только с тем, что я использую слово «вырожденный»? Если первое, то нам следует поговорить об этом. Если второе, то можем ли мы закончить этот спор, изменив «все, кроме самых вырожденных» на «большинство»? Cjoev 04:41, 24 мая 2006 (UTC) [ ответить ]

Ну, дело в том, что типы различаются на семантическом уровне, а не на уровне реализации. Если бы (гипотетически) у вас были float и integer одинаковой длины в битах, любой битовый шаблон был бы действителен для любого из них, но любой заданный битовый шаблон (кроме 0000 0000 ... ) означал бы что-то разное в каждом типе. Я бы рассматривал точные битовые шаблоны, разрешенные для типа, как незначительную техническую деталь; они не связаны по сути с природой типа , которая заключается в назначении семантического значения битам и определении взаимодействий с битами, назначенными по-разному. Поэтому я бы вообще не упоминал битовые шаблоны.

Хм. Если « природа » типа заключается в том, чтобы присваивать семантическое значение битам , то как можно ожидать, что битовые шаблоны будут исключены? Cjoev

Потому что все можно обобщить как бит-шаблон, но это обычно не имеет значения для какой-либо конкретной точки в рассматриваемой вещи. Для безопасности типов неважно, одинаковые бит-шаблоны или разные, важно, чтобы значение было разным. — Simetrical ( обсуждение  •  вклад ) 03:44, 11 июня 2006 (UTC) [ ответить ]

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

Или, по крайней мере, так я это вижу, прочитав статью. Нет необходимости привносить сюда битовые шаблоны: даже если неинициализированные данные, которые вы считываете в переменную, совпадают с битовыми шаблонами, разрешенными типом , вы все равно нарушили безопасность памяти, считывая их. — Simetrical ( обсуждение  •  вклад ) 05:52, 25 мая 2006 (UTC) [ ответить ] ${\displaystyle t}$

Я рассуждал в двух направлениях. Вопрос о битовых шаблонах был в первом направлении, а именно, что языки, небезопасные для памяти, также небезопасны для типов. Здесь аргумент заключается в том, что если вы можете читать из безумного места, вы не можете ожидать получить разумное значение. Загвоздка в том, что если все значения считаются разумными, в том смысле, что все, что вы можете прочитать из любого места в памяти, имеет смысл как член любого типа, то, конечно, вы можете ожидать получить разумное значение. Тот факт, что вы нарушили безопасность памяти, прочитав их, ничего не значит, потому что я уже предположил, что язык небезопасен для памяти, и пытаюсь утверждать, что он, следовательно, также небезопасен для типов. Так что для того, чтобы аргумент о том, что небезопасность памяти нарушает безопасность типов, выдержал критику, должно существовать какое-то безумное значение, которое может быть прочитано из безумного места. Мой аргумент в другом направлении, что определенные виды поведения, небезопасного для типов, также нарушают безопасность памяти, не имел ничего общего с битами, тривиальностью или вырожденностью. Cjoev 00:07, 26 мая 2006 (UTC) [ ответить ]

Если вы возьмете случайные биты и скопируете их в C int, вы нарушите безопасность типов (если только вы не намеревались создать случайное или иным образом произвольное число, в этом случае копирование битов — это просто способ сгенерировать псевдослучайное число). Результатом будет целое число, но совершенно бессмысленное. Ну и что, если там будет написано:

Безопасность типов тесно связана с так называемой безопасностью памяти . Чтобы понять почему, предположим для целей обсуждения, что определенная реализация определенного языка имеет некоторый тип, скажем , такой, что существует некоторый ${\displaystyle t}$последовательность битов (соответствующей длины)концепция, который не является допустимым членом . (Все, кроме самых вырожденных систем типов, удовлетворяют этому критерию.) Если этот язык небезопасен с точки зрения памяти в той степени, что позволяет копировать данные из нераспределенной или неинициализированной памяти в переменную типа , то он не является безопасным с точки зрения типа, поскольку такая операция ${\displaystyle t}$ ${\displaystyle t}$мощьбыназначить не- ${\displaystyle t}$ ценитьзначениек этой переменной. И наоборот, если язык типобезопасен настолько, что позволяет использовать произвольное целое число в качестве указателя, то он явно не является безопасным по памяти.

— Simetrical ( обсуждение  •  вклад ) 03:44, 11 июня 2006 г. (UTC) [ ответить ]

За время, прошедшее с того момента, как я последний раз заглядывал в эту дискуссию, я забыл, почему, как мне казалось, я говорил «последовательность битов». На самом деле я хотел написать «значение», но по какой-то причине решил этого не делать. Я думаю, что «концепция» излишне абстрактна. Нарушит ли присвоение безопасность типов или просто «может» — зависит от того, как язык определяет результат — серая зона, о которой многие неформальные определения языков умалчивают. Я смело заменю «последовательность битов» на «значение». Cjoev 18:44, 15 сентября 2006 (UTC) [ ответить ]

Отмененные удаления

Я только что отменил крупную правку, которая удалила большие объемы контента с недостаточным объяснением: худшей из них было удаление всего раздела об управлении памятью на основании того, что "сборка мусора не имеет ничего общего с безопасностью типов", тема, которая уже широко обсуждалась на этой странице. Другие удаления включали известный слоган Робина Милнера, кивок в сторону денотационной семантики и слегка философское обсуждение значения "небезопасного". Cjoev 21:55, 22 сентября 2006 (UTC) [ ответить ]

Java и Standard ML не имеют доказательств безопасности типов

Утверждение "требуется цитирование", что Java и Standard ML имеют доказательства безопасности типов, ложно. Нет доказательства безопасности типов ни для одного языка, официально признанного как Java. Доказательство безопасности типов для языка, который является небольшой дельтой от SML97, находится в процессе (почти завершено, насколько мне известно) работы в CMU.

Для Java не существует доказательства безопасности типов, поскольку Java не является типобезопасной: см. [5].

С другой стороны, эта дыра в системе типов требует использования нескольких загрузчиков классов, поэтому может считаться необычной позицией для разработчиков. В большинстве случаев Java является типобезопасной. Я мог бы предположить, что статья сохраняет утверждение, что это так, со ссылкой на эту статью. JoeKearney 09:58, 1 июня 2007 (UTC) [ ответить ]

Как отмечено выше, Java (язык) определенно является типобезопасным. Ошибки в конкретных реализациях виртуальной машины Java (которые демонстрирует статья Сарасвата) являются совершенно отдельной проблемой. Однако, насколько мне известно, никогда не было формального доказательства того, что Java является типобезопасным (что, учитывая сложность практически всех неигрушечных языков, является обычным явлением). То есть, нас не должно волновать, что Java не была математически доказана как типобезопасная, как и практически все распространенные языки программирования. Достаточно заявить, что Java является типобезопасной по своей сути , и это все, что нас действительно волнует в этой статье. trims2u 21:43, 19 июня 2011 (UTC) [ ответить ]

Статья Сарасвата претендует на демонстрацию проблемы безопасности типов не в конкретной реализации JVM, а в самой спецификации JVM. Если вы хотите утверждать обратное, пожалуйста, предоставьте ссылку. (Кроме того, текущий текст подразумевает, что проблема больше не существует. Если это правда — а я в это верю — то она также должна иметь ссылку.) — Ruakh _TALK 14:36, 21 июня 2011 (UTC) [ ответить ]

Sarawat указывает на потенциальную проблему в оригинальной спецификации Java, которая приводит к возможной уязвимости в JVM, реализующей раннюю спецификацию Java VM. Ошибка Sarawat была устранена в спецификации Java 1.2, и все виртуальные машины, реализующие эту спецификацию или более позднюю, не демонстрируют этот недостаток. Более поздние обсуждения обнаружили несколько других проблем с загрузкой классов, которые впоследствии были исправлены. Все это говорит о том, что дизайн Java должен быть типобезопасным; как и все остальное программное обеспечение в этом мире, ошибки могут поставить под угрозу эту цель. Trims2u ( обсуждение ) 10:05, 30 января 2012 (UTC) [ ответ ]

Степени или интерпретации безопасности типов

Я хотел бы добавить некоторую общую или вводную информацию в статью относительно интерпретации безопасности типов на основе контекста. По моему опыту, существуют степени безопасности типов, от "ужасной" - например, в ассемблере, где компилятору обычно вообще невозможно отслеживать какую-либо информацию о типе - до C, где компилятор, по крайней мере, выдает предупреждение во время неявного преобразования типов для проверки намерений программиста, до определенных ситуаций в C++, где для проверки намерений программиста требуется использование reinterpret_cast. Это правда, что ни одна из этих ситуаций не является "строго типобезопасной", но я считаю, что их следует включить в информационных целях. Reinderien ^{talk / contribs} 20:52, 8 августа 2008 (UTC) [ ответить ]

Противоречиво?

Это кажется кому-то еще противоречивым, или я что-то не понимаю? "Типовая безопасность — это свойство языка программирования, а не самих программ. Например, можно написать безопасную программу на типонебезопасном языке". Если это не свойство программы, как можно написать типобезопасную программу? — Предыдущий комментарий unsigned , добавленный 96.242.156.9 (обсуждение) 00:53, 5 октября 2008 (UTC) [ ответить ]

Да, мне это тоже кажется противоречивым.-- 151.202.239.74 ( обсуждение ) 20:09, 29 июля 2009 (UTC) [ ответ ]

Вам нужно обратить внимание на пропущенные слова: он говорит о написании программы сохранения, а не о не-программе сохранения типов. Типичный аргумент сторонника языков, не поддерживающих тип. И это правда — вам просто нужно самостоятельно выполнять все функции безопасности, которые предоставляет язык сохранения типов. Только человек никогда не делает это так надежно, как автоматизированный процесс языка программирования. -- Krischik  ^T 16:21, 10 августа 2009 (UTC) [ ответить ]

да, это звучит противоречиво. Возможно, он не говорит о программе сохранения типа, но слова "Например..." не приводят к такому выводу. —Предыдущий неподписанный комментарий добавлен 79.154.168.94 (обсуждение) 08:44, 2 декабря 2009 (UTC)[ отвечать ]

Нет, это не противоречие. Безопасность типов — свойство языков. Возможно, можно писать программы с правильным типом на языках, не являющихся безопасными, но невозможно писать программы с неправильным типом на языках, являющихся безопасными. Вот в чем заключается безопасность типов. Эдуардо Леон (обс.) 15:08, 27 июня 2013 (UTC) [ ответить ]

Типобезопасность и «строгая типизация»

Понятие «безопасности типов» в так называемых «динамически типизированных» (на самом деле, юнитизированных) языках бессмысленно. Безопасность типов заключается в предотвращении сбоев . Следует отметить, что все неправильные приведения типов приводят к сбоям в работе программ — просто некоторые юнитизированные языки делают эти сбои более очевидными (например, Python), в то время как другие пытаются замаскировать эти сбои под странные формы «успеха» (например, JavaScript). Эдуардо Леон (обс.) 15:15, 27 июня 2013 (UTC) [ ответить ]

Типовая безопасность Системы F

Это заполнитель для тега «обсудить». Я с нетерпением жду этого обсуждения. Моя цитата взята из объяснения Пейтона-Джонса ядра GHC. Я планирую аннотировать свой вклад временными метками в видеоклипе. ^[1] -- Ancheta Wis   (обсуждение | вклад) 18:06, 14 декабря 2017 (UTC) [ ответить ]

Ссылки

1. YouTube: Вглубь ядра — втискивание Haskell в 9 конструкторов, Саймон Пейтон-Джонс (14 сентября 2016 г.), Erlang Conference