Есть ли в CL и C алгебраические типы данных?

Похоже всё верно, но тред почему-то уныл донельзя

Про лисп не знаю. Про C все верно, правда, вся силища именно в образцовости, потому про C-шные union-ы такой восторженности не встречается.

http://www.nsu.ru/xmlui/bitstream/nsu/8874/1/Harrison.pdf ,стр. 68: «Этот тип данных аналогичен конструкции union языка C» .

И вообще, книжка хорошая. Вторую часть, что про ML, читать и интересно, и полезно.

Протестую! Треды типа «Ну и что, что в X есть Y? Оно нах не надо» - единоличная прерогатива анонiмуса :)

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

если это анонiмус, то как он набил три звезды? Может он просто угнал аккаунт?

Кстати где он? Я скучаю. Даже Хьюита всего пересмотрел и на смолтолке пару хеловордом написал.

cast tailgunner. Он тут рассказывал про свою наколенную библиотеку с ADT на C.

таки да, одно дело 'технически что-то подобное есть', но на практике никому лучше от этого не становится потому что за использование нестандартных приёмов в рамках технологии оторвут руки

В лиспе - несколько структур и or.

а проверка на этапе компиляции? без неё всё теряет смысл

По-моему, автору это нафиг не нужно. Но у меня просто шаблон, генерирующий тот самый union с тегом.

Лисп кое-что может проверять с or-ами. Орально, так сказать. А я не вбрасываю, я доклад пишу :)

Онанизмом ты занимаешься.

Кстати где он? Я скучаю.

xlsparse.

Верно подмечено

уже почти страница игнор листа из-за него :)

произведением почему-то называется
почему-то

Facepalm.

ГДе произведением почему-то называется рекорд из таких типов.

Сумма - это размеченное объединение, а не обычное.

То есть можно: type = C1 Integer | C2 Integer, с or ты так не сделаешь

В общем-то всем спасибо.

эта идея важна, если ты кодишь на хашкеле

Путаешь просто алгебраические типы данных (record в хаскеле) и обобщенные алгебраические типы данных (GADT). Последние в хаскеле, действительно, сила.

алгебраические типы данных (record в хаскеле)

Здесь сказал бред, record не относятся к ADT.

просто алгебраические типы данных (record в хаскеле)

data

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

https://github.com/eudoxia0/magma#algebraic-data-types

Просто некоторые упорыши типами называют не сами типы, а то как их компейлятор проверяет

А другие упорыши считают, что типы существуют, даже если компилятор о них ничего не знает. У этих упорков есть все мыслимые системы типизации - от динамической до зависимых типов. Правда, на практике толку от этого нет, но упоротых это не волнует.

Правда, на практике толку от этого нет

Говорить такое может только идиот, ведь ошибка в рантайме чуть менее чем всегда лучше неправильного результата.

Говорить такое может только идиот

Ты обиделся за товарища чтоли?

ведь ошибка в рантайме чуть менее чем всегда лучше неправильного результата.

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

Ошибка в рантайме, конечно, лучше, чем неправильный результат. А ошибка при компиляции лучше ошибки в рантайме.

Ха вот ты дурачек. Неужели думаешь что типы без компилятора существовать не могут?

Ха вот ты дурачек

дурачек

Ха, вот ты слабоумненький.

Неужели думаешь что типы без компилятора существовать не могут?

Неужели ты нашел это в моих словах?

Скорее в твоем «высере» - словами это сложно назвать.

в твоем «высере»

В содержимом твоей головы.

У тебя кукушонка съезжает?

Если другие кажутся тебе психами - немалые шансы, что ты сам псих.

А другие упорыши считают, что типы существуют, даже если компилятор о них ничего не знает.

В динамических языках компилятор о типах знает. Иначе он код скомпилировать не сможет.

А ошибка при компиляции лучше ошибки в рантайме.

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

А ошибка при компиляции лучше ошибки в рантайме.

Это неверно. Лучше та ошибка, которую проще обнаружить и исправить

Да. И проще обнаружить и исправить те ошибки, которые проявляются во время компиляции.

еще лучше та, у которой ниже стоимость факапа, но это уже не про типизацию

Это тоже про типизацию.

рантайм указывает точное место ошибки и ее характер, а тайпчекер - нет

Проверка типов в рантайме ровно никак не противоречит проверкам типов тайпчекером.

Проверка типов в рантайме ровно никак не противоречит проверкам типов тайпчекером.

Противоречит. Программа не скомпилируется => тест не запустится и у тебя не будет корректного сообщения об ошибке.

Да. И проще обнаружить и исправить те ошибки, которые проявляются во время компиляции.

Это не так. Еще раз - существует целый класс ошибок, который проще обнаруживать в случае рантайм-ошибки.

Это тоже про типизацию.

Нет, не про нее. Типизация ничего не знает и знать не может о том, сколько $ будет потрачено в случае пропуска той или иной ошибки.

Еще раз - существует целый класс ошибок, который проще обнаруживать в случае рантайм-ошибки

...для некоторого значения «проще».

Типизация ничего не знает и знать не может о том, сколько $ будет потрачено в случае пропуска той или иной ошибки.

От запуска программы на трансляцию $ не тратятся. Разве что транслятор взят в аренду.

...для некоторого значения «проще».

Для вполне обычного значения - требует меньше времени и усилий.

От запуска программы на трансляцию $ не тратятся.

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

существует целый класс ошибок, который проще обнаруживать в случае рантайм-ошибки

А можно минимальный пример, чтоб точно понимать о каких ошибках идет речь?

А можно минимальный пример, чтоб точно понимать о каких ошибках идет речь?

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

Ни один из современных чекеров не в состоянии в данном случае выдать вразумительное сообщение, в то время как эррор в рантайме укажет все, что нужно и как нужно.

Да нихрена он не укажет больше, чем указал бы тайпчекер.

Да нихрена он не укажет больше, чем указал бы тайпчекер.

Конечно, укажет, ведь рантайм знает, где что упало, а чекер - не знает, где оно должно упасть. В рантайме строго большее количество информации о программе.

Конечно, укажет, ведь рантайм знает, где что упало, а чекер - не знает, где оно должно упасть. В рантайме строго большее количество информации о программе.

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

Ошибка не обязательно находится там где упало.

Обязательно, конечно же.

Тайпчекеру же доступно больше информации, чем есть в рантайме.

Что за бред? У чекера нету никакой информации, которой не было бы в рантайме.

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

Зачем?

Тайпчекер тебе точно скажет, в чем проблема

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

Тайпчекер выполняет часть этой работы за тебя.

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

Обязательно, конечно же.

Нет, т.к. без проверки типов может быть нарушена целостность данных.

Что за бред? У чекера нету никакой информации, которой не было бы в рантайме.

Может и быть, зависит от реализации и степени оптимизации рантайма.

Зачем?

Затем, что «ошибка не обязательно находится там где упало» (с).

Каким образом он это скажет, если он, грубо говоря, не знает таких терминов даже?

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

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

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

Обязательно, конечно же.

Просто наглая нелепая ложь!

Что за бред? У чекера нету никакой информации, которой не было бы в рантайме.

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

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

Нет, с динамической типизацией тебе придется бектрейсить по вызовам, чтобы найти проблему. И даже в этом случае ты можешь её не найти. Тайпчекер сразу же, как только выдаст ошибку, укажет тебе все, что нужно знать для решения проблемы.

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

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

Просто наглая нелепая ложь!

Что, прости? Каким образом это может быть не так? Мы о рантайме, напоминаю. Как то место, в котором программа отвалилась, может не быть тем местом, в котором программа отвалилась?

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

Это так при слабой типизации. При сильной типизации рантайм имеет строго большую информацию о типах, чем тайпчекер.

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

Зачем? Ни разу не встречал такого.

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

Чекер в отличии от рантайма вообще не может сказать ничего об ошибке. Он говорит о несоответствии типов или о невозможности вывода, и это все, никакой другой информации у него нет by design, это рантайм знает об исполнении, чекер знает только о типах. Несоответствии типов в случае типов сложнее простейших мономорфных и часто ничего не говорит о характере ошибки. В случае вывода типов - местоположение факапа может быть вообще где угодно и не говорит ничего о местоположении ошибки.

Затем, что «ошибка не обязательно находится там где упало» (с).

Это если говорить об ошибках в общем, тут конечно ошибка в одном месте программы может отозваться в любом другом. Ошибка же типов (если речь идет о системах типах слабее, чем зависимых, например типизации на базе SystemF) ВСЕГДА находится там, где упало.