Одно свойство размеченного объединения - то, что можно тип узнать. Оно важное, не спорю. В Си прямо так на уровне типов это выразить нельзя, но в лиспе можно. Какие ещё есть важные свойства?
Одно свойство размеченного объединения - то, что можно тип узнать. Оно важное, не спорю. В Си прямо так на уровне типов это выразить нельзя, но в лиспе можно.
неразмеченный union вообще не является типом - ты просто в принципе не знаешь, что в нём хранится, эту информацию нужно как-то отдельно хранить. Вот это и нельзя выразить - тип данных. В лиспе если у тебя есть два непересекающихся типа a и b, то ты можешь создать тип (or a b) и я пока не вижу чем он отличается от sum type.
Если хаскелеводы смогут существенное сказать про профит АТД, то можно будет сказать, что это не прямая ложь. Если единственное достоинство - в pattern matching, который является лишь инструментом, то сказанное по ссылке - прямая ложь и Хаскель - это секта.
ну, формально, если язык поддерживает алгебраические типы, то на уровне языка будет поддержка ограничений. а если как в си, то не пофиг ли, теггед - не теггед? надо кучу функций написать ручками дабы обеспечить доступ к данным и в любом случае никто не мешает отсрелить себе почки целясь в пролетающую утку.
Я же тебе сказал, атд такие какие есть, потому что эта конструкция обладает «хорошими» свойствами с теоретической точки зрения. Про нее можно доказывать разные хорошие теоремы ит анализировать при помощи развитого матаппарата. При замене размеченных объединений обычными все силньо ломается.
вообще видел когда то на стековерфлоу хороший примерчик, но найти не могу сейчас, к сожалению. но по сути там был то ли дистрибутивный закон, то ли ещё какая то простая математика.
Спасибо. Т.е. по сути, тегированные юнионы + рассуждения о типах на них В этом смысле да, в лиспе нет рассуждений о типах. Хотя сами помеченные юнионы делаются элементарно:
Но компилятор не будет проверять, что тег соответствует значению. Видимо, в этом и разница. Но я, если оставить в стороне пропаганду, положа руку на сердце не сказал бы, что в Хаскеле «есть» эти типы а в Си «нет». Нужно различать возможность записать этот тип и операции, которые можно делать с этим типом. Паттерн матчинг и вывод типов - это своего рода операции, или, если угодно, метаоперации.
положа руку на сердце я бы поддержал тейлганнера: по моему ты не отличаешь «встроена» и «может быть выражена»
ну или не желаешь отличать чтобы оказаться правым в своём упорствовании.
чем тогда обычный ассоциативный массив в php не сум тайм? если городить из говна и палок, действительно, то всё сум тайп. одна проблема с этим сум тайпом - пока нагородишь, весь в говне поперепачкаешься. ну или перчатки надо по уши натягивать.
Tagged union (который иногда называют Sum Type, но это плохое название) - это union.
Из этих двух способов конструируются новые типы из уже существующих, при этом возможна рекурсия (структура может иметь полем саму себя).
В большинстве ЯП АДТ есть (вопреки пропаганде хаскелеводов). Я не знаю точно, но догадываюсь, что единственное, чем Хаскель реально выделяется - так это контролем связи между тегом и значением в tagged union на уровне компилятора. Ещё есть pattern matching, но это уже совсем ортогонально и не будем об этом.
С моей колокольни ситуация выглядит так: в Хаскеле улучшенная инструментальная поддержка АДТ и введено, собственно, понятие об АДТ. Но нужно отличать возможность выразить тип и способность компилятора судить о коде. Если мы рассмотрим отдельно возможность выразить тип, то Хаскель ничем не отличается от других языков.
Если мы рассмотрим отдельно возможность выразить тип, то Хаскель ничем не отличается от других языков.
как верно заметил выше devzero, ты можешь хоть на ассемблере выразить сум тайп, ибо тьюринг полнота. вопрос только зачем называть это сум тайпом? какой в этом смысл? потешить себя мыслью что «хаскелисты секта» и всего?
Ну в общем-то воля твоя, какого мнения о моих неотличаниях вы с тейлганнером придерживатесь, мне это более-менее фиолетово.
Тут проблема в другом: уже многократно Хаскелеводы были пойманы на том, что они придумывают новые названия для рагу из зайца и долго бьют себя пяткой в грудь, уверяя всех в уникальности Хаскеля. При этом мало кто реально понимает (и может простыми словами объяснить) в чём профит и вообще что означают эти заклинания. Такое поведение - это типичное сектоводство, когда разум неофитов подавляется введением понятийного аппарата, призванного исказить реальность.
Поэтому да, я предвзят отноительно Хаскеля. Но дело не в этом. Я честно пытаюсь понять, что даёт АДТ для практики, с той точки зрения, нужно ли включать их в планы для включения в ЯП, к-рый я создаю.
Некоторые люди сразу просто говорят, а тейлганнер вместо этого пытается отлаживать мой мозг, этим мне он и не нравится, и даже хочется его забанить.
Один профит я понял - контроль связи между тегом и содержимым. Но явно мне это никто не сказал - мне говорили о «хороших свойствах» и т.п. Мутность мышления, неясные посулы без конкретики с декларацией превосходства, в которое я должен поверить - это тоже из сектоводтсва.
Но допустим, такой контроль есть. Конкретно: есть некая конструкция «разобрать все случаи тега типа». Внутри каждой клаузы компилятор обругается на использование значения, не соответствующего тегу. А также он опционально обругается, если я рассмотрел не все теги. Это понятный профит и думаю, что он есть в Хаскеле.
Это реальный профит. Для справки отмечу, что здесь есть сходство с наследованием и я нашёл одну статью об имитации АДТ с помощью наследования (правда, там были и дефекты).
Но какие ещё «хорошие свойства» у них есть - мне никто не сказал. При этом мне навязывают чуждую мне терминологию, зачем-то напридумывали новых названий для известных вещей. После того, как я всё эту шелуху счистил, остаётся ощущение, что я зря трудился, потому что в сухом остатке почти что ничего (кроме того самого контроля). Т.е. меня опять кинули, как и должно случиться с тем, кто приходит в секту.
Тут проблема в другом: уже многократно Хаскелеводы были пойманы на том, что они придумывают новые названия для рагу из зайца и долго бьют себя пяткой в грудь, уверяя всех в уникальности Хаскеля
Algebraic data types were introduced in Hope, a small functional programming language developed in the 1970s at Edinburgh University.
По моему про паттерн матчинг тебе ленивый не сказал только. Просто когда человека спрашивают «профит» он сразу про паттерн матчинг, ибо реальный профит. А ты это требуешь в форме «контроль связи между тегом и содержимым». Я ж тебе сразу сказал - проверка компилятором. Нес па? А без этого пишешь кучу мутных функций руками. Ты не доволен. Может ты просто немного не владеешь терминологией? Коли ты уж спрашиваешь про сум тайп то очевидно что ответ прилетит в виде «алгебра типов » и «паттерн матчинг», а не в виде «контроль за содержимым тегов». Если хочешь услышать «контроль за содержимым тегов», мне кажется надо спросить «какой смысл теггировать юнионы в си». вот тут да, «контроль за содержимым типов» (ну, если ручками наговняешь из палок этот контроль, конечно, то да, и то с оговорками)
Паттерн-матчинг - это не просто удобство, а единственный (?) способ сохранить статичную типобезопасность ADT. Без него вообще нет смысла говорить что в языке есть ADT, ибо нет самой алгебры.
Product type - запись (рекорд, структура)
Tagged union (который иногда называют Sum Type, но это плохое название) - это union.
jeezus christ, у лисперов всегда такая каша в голове? Есть теоретико-категорные понятия произведения и суммы (копроизведения) объектов, а объекты, которые являются произведениями или суммами объектов называем product object и sum object. Когда у нас есть категория в которой объекты это типы, то тогда говорим о product type и sum type. :-)
Записи, структуры и прочие tagged union — это конкретные способы реализации product или sum type. :-)
В большинстве ЯП АДТ есть (вопреки пропаганде хаскелеводов).
Haskell это категория Hask, где объектами являются типы Хаскеля, а морфизмами — функции Хаскеля. И известно, что там есть произведения и суммы типов. Поэтому мы можем говорить о наличии АДТ. :-)
Как можно говорить о том, что в ЯП есть АДТ, если для этих «большинства ЯП» не определена категория типов? :-)
Хорошо когда может быть выражена(в тч синтаксически). Когда встроена — не всегда хорошо.
Реализация на уровне языка ничего не меняет в принципе, играет лишь косметическую роль и улучшает производительность.
Но, как правило, само по себе обилие синтаксических «встроенных» конструкций и фич говорит о слабости языка. Просто потому что мощный язык не нуждается в обилии сахара и фич, поскольку это все легко реализуется на пользовательском уровне.