Что круче: Лисп или Хаскелль?

> Хм, что значит были изменены?

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

Это было бы удобно, если бы SLIME перекомпилировала все используемые функции в данной автоматически, если они были изменены. Хотя это скорее проблемы моей забывчивости, таки да :).

> Почему именно на «монотипах»?

Ну вот такое определение у систем с подтипированием, чего же я сделаю?

Ну не позорься. Ну нет такого типа «жопа».

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

К типу forall a. a -> a применимы все операции, применимые к типу Int->Int.

Это полиморфизм, а не сабтайпинг. forall a. a -> a не подтип для Int->Int. Просто потому что подтипирование определено на монотипах, а forall a. a -> a - не монотип. Вот если бы можно было в хаскеле объвить тип вроде: «deftype Type = forall a. a» - но этого нельзя. Вообще, я, возможно, неверно выразился, при сабтайпинге мы можем _потребовать_ от компилятора чтобы для Х выполнялись все операции Y. То есть компилятор не выводит этот факт из каких-то соображений - мы можем его указать, явно. В хаскеле мы указать это не можем.

Нет, особенность полиморфизма. В Хаскеле работает, в жабе работает, в шарпе работает. В плюсах - хрен.

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

Там, где ты будешь собирать конкретную реализацию.

Можно конкретно, с кодом?

Отнюдь.

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

> Понятно, что такое «определение» ты тоже не в курсе.

Да, как и Георг Кантор. Вот такие мы с ним два идиота - не знаем, что такое определение :( А еще, там специально для тебя была приписка - можно определить и аксиоматически. Ну например, проще всего определить пусто множество. Х есть пустое множество, если Х может быть элементом множества и если Х не содержит никаких элементов (все по ZFC, короче). Пустой мешок удовлетворяет обоим этим свойствам, а значит, является пустым множеством.

> Монада есть функтор.

Чушь, конечно. Одному функтору может соответствовать куча разных монад. Можно сказать, что _некоторые функторы_ являются _классами эквивалентности монад_. не более того.

Композицию функторов определять?

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

> Ты изобрёл третий?

НеТ, его изобрели те, кто придумал ООП. А, что, по-твоему бывает только два вида полиморфизма?

> Кому должен? Тебе? У тебя функция определена для Num'ов. Хочешь чтобы вывели Int, используй результат как Int. А так из двух Num'ов, на стадии компиляции был выбран более общий.

Ну вот именно, он вывел более общий тип, а нужен был менее общий. В результате чекер пропускает некорректный код. Вот если бы полного тайп инференса не было, мне пришлось бы самому написать декларацию для f. А так компилятор позволяет мне ее не писать в результате - ошибки.

> Но вызываемые измененной функцией функии не перекомпилируются, даже если были изменены со времени последней загрузки, подобно тому как это происходит в emacs lisp, если их явно не перекомпилировать?

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

Ну вот такое определение у систем с подтипированием

Большинство систем с подтипированием вообще не знают, что такое «монотип» и «политип».

В системах с сабтайпингом жопа всегда есть.

В C++?

forall a. a -> a не подтип для Int->Int

Подтип.

Просто потому что подтипирование определено на монотипах

Это твои личные сексуальные фантазии.

при сабтайпинге мы можем _потребовать_ от компилятора чтобы для Х выполнялись все операции Y.

Какие-то у тебя странные понятия о сабтайпинге. С чего ему обязательно быть явным - не пойму. Но ладно, готов признать: ЯВНОГО сабтайпинга в хаскеле нету.

Ну параметричечкий полиморфизм там, очевидно, не при чем.

Да нет, вот ровно он и работает.

Лямбда двойка тоже не позволит так написать

Зависит от твоего понимания слов «лямбда двойка».

> У меня в eLisp часто случалось забывать перекомпилировать все

функции после их переопределения

Во-первых, там это гораздо менее удобно.

Хотя это скорее проблемы моей забывчивости

Нет, дело не в забывчивости. Не зря же лисперы твердят REPL, REPL, REPL. Каждый чих постоянно отправляется и проверяется в REPL. Это такой стиль разработки - постоянный, непрекращающийся диалог между разработчиком и средой. Его нужно просто освоить.

Можно конкретно, с кодом?

Можно, делай.

Так же как мешок с картошкой удовлетворяет определению гладкого многообразия

Нет.

хаскимонада удовлетворяет определению монады.

Ну, тройки Клейсли. Эквивалентная весч.

Да, как и Георг Кантор. Вот такие мы с ним два идиота - не знаем, что такое определение

Ты ещё Архимеда вспомни.

Нормальные определения пошли где-то с Гильберта.

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

Не-а. Пустой мешок не может быть элементом множества. Элементами множества могут быть только математические объекты, в число коих мешок не входит.

Одному функтору может соответствовать куча разных монад.

Да, разумеется.

Точно так же на одном множестве можно ввести кучу структур группы.

Что не отменяет того факта, что группа есть множество.

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

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

НеТ, его изобрели те, кто придумал ООП.

Да нет, дружище, они, как раз, работали исключительно в рамках ad-hoc.

> Большинство систем с подтипированием вообще не знают, что такое «монотип» и «политип».

И? Как это отменяет тот факт, что отношение подтипирования устанавливается для монотипов?

В C++?

Что с++?

Подтип.

Не подтип. forall a. a -> a - тип полиморфной функции, Int->Int - тип функции из Int в Int. Никакая ф-я Int->Int не является функцией forall a. a->a и наоборот - никакая функция forall a. a->a не является функцией Int->Int. Если ты считаешь, что это-таки подтип - то это очень просто доказать. Если X подтип Y, то ф-ю с типом X->Z для любого Z можно применить к аргументу типа Y (в этом и смысл подтипов). Напиши мне, пожалуйста, в хаскеле ф-ю с типом f : (forall a. a -> a) -> z (квантор внутри!) такую, что она будет принимать ф-ю с типом Int -> Int.

Это твои личные сексуальные фантазии.

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

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

С того, что вот так вот определяются системы с сабтайпингом.

Зависит от твоего понимания слов «лямбда двойка».

простая типизированная лямбда с полиморфизмом. Ну добавим к ней ADT, Integer и Bool.

perl.

Как это отменяет тот факт, что отношение подтипирования устанавливается для монотипов?

Да его и не было никогда.

Что с++?

Где там тип «жопа»?

Если X подтип Y, то ф-ю с типом X->Z для любого Z можно применить к аргументу типа Y (в этом и смысл подтипов).

Только наоборот. Любою функцию Y->Z можно применить к аргументу типа X.

Напиши мне, пожалуйста, в хаскеле ф-ю с типом f : (forall a. a -> a) -> z (квантор внутри!) такую, что она будет принимать ф-ю с типом Int -> Int.

Как уже говорилось, наоборот. Функцию с типом (Int -> Int) -> z, которая примет (forall a. a -> a). Легко:

f i = i 1
main = print (f id)

> Можно, делай.

Что делать-то?

Ну, тройки Клейсли. Эквивалентная весч.

и?

> Не-а. Пустой мешок не может быть элементом множества. Элементами множества могут быть только математические объекты, в число коих мешок не входит.

В ZFC нигде ничего не говорится про какие-то «математические объекты». Там вообще никаких объектов нету - там есть только переменны. а какие значения эти переменные могут принимать - зависит от интерпретации, которую мы выберем. Никто не запрещает нам выбрать в качестве интерпретации мешки, главное, чтобы такие мешки удовлетворяли аксиомам. Они и удовлетворяют.

> Что не отменяет того факта, что группа есть множество.

Группа - это не множество, группа - это упорядоченная тройка. Множеством будет носитель группы (элемент этой тройки), но не сама группа (вообще, конечно, любая трйока тоже представляется в виде множества, но ты понял, что тут имеется в виду).

О чём я и говорю: композиция монад может не быть монадой.

Я еще раз задам вопрос - что такое композиция монад?

> Да нет, дружище, они, как раз, работали исключительно в рамках ad-hoc.

Да ничего подобного, ad-hoc полиморфизм - это все же из области статики, а виртуальные функции - это тот же смоллтолк, то есть ядреная динамика. Никакого ad-hoc полиморфизма там и рядом не бегало.

> Да его и не было никогда.

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

Где там тип «жопа»?

for (; 1 ;) 0; какой тип у этого терма?

Только наоборот.

Ну да.

Как уже говорилось, наоборот. Функцию с типом (Int -> Int) -> z, которая примет (forall a. a -> a). Легко:

А вот и нет, у тебя в данном случае id имеет тип int->int (во время тайпчека полиморфный аргумент будет уже разрешен и id неполиморфна). Надо вот так:

f : (forall a. a -> a) -> Int

g : Int -> Int -> Int

g i = i 1

f fun = g fun

f id

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

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

Вот поэтому C++ и жив.

> Вот поэтому C++ и жив.

Хм, как это объясняет использование С++ для проектов типа MongoDB, Sphinx или там V8?

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

Вот поэтому C++ и жив.

а жаль, а жаль...

лисп, потому что патрег бох

//тред не читал

Я еще раз задам вопрос - что такое композиция монад?

такой ответ тебе подойдёт?

>>Группа - это не множество, группа - это упорядоченная тройка.

Садись. Двойка.

> Группа - это не множество, группа - это упорядоченная тройка.

Какая ещё тройка? Группа это множество и групповая операция на нём вида X*X -> X, где X - групповое множество(плюс групповая операция должна удовл. опр. условиям).

Группа это множество и групповая операция на нём

строго говоря, это ещё и нейтральный элемент относительно этой операции. любая группа является моноидом

хотя в любом случае это буквоедство. можно ведь сказать и так, что группа - это алгебра F a -> a (с некоторой сигнатурой F). что толку в подобном терминологическом споре, если все понимают, о чём идёт речь?

> Затем они не смогли сделать нормальные шаблоны — я молчал, ведь были языки с нормальными шаблонами.

это какие языки?

> "(" --- α и ")" --- ω. Начало и конец.

Исправлено.

> я уж тут на лоре писал, что вывести unsigned в account.send_money_to(Account receiver, unsigned int money) нереально и катастрофически ненадежно

Давай по-подробнее - о чём речь? Как доказать, что account.send_money_to(..) всегда возвращает unsigned, т.е. > 0 ?

> Вот есть процедура, печатающая имя типа переданного ей значения. Как ты тут без тайптега?

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

>> Вот есть процедура, печатающая имя типа переданного ей значения. Как ты тут без тайптега?

Отследить все вызовы этой процедуры

Гыгы.

> Какая ещё тройка?

Тьфу ты. Пара, конечно же, а не тройка :)

> строго говоря, это ещё и нейтральный элемент относительно этой операции. любая группа является моноидом

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

Благодарю.

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

А где это у нас нет проблемы останова?

А где это у нас нет проблемы останова?

в нейросетях с иррациональными весами :)

> Группа это множество и групповая операция на нём вида X*X -> X
А ещё нейтральный элемент, и всё это добро пишут как тройку (впрочем, это зависит от учебного пособия).

>Depends. Два наиболее известных DSL-я - это HTML и SQL. Каждый из них >в жабоскриптовом синтаксисе будет выглядеть очень нелепо. В Хаскельном >SQL можно сделать почти таким же, как есть сейчас, а HTML... ну, >более-менее похожим.

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

И что? Оборачивать его в скобочки? Или строкой передавать? Но если передаёшь строкой,то возникают другие проблемы: " превращается в \".
Вроде мелочь, но если проводишь за SQL 8х5 в неделю, это - серьёзный недостаток.

В итоге пришёл к тому, что синтаксис SQL должен остаться неприкосновенным. Т.е.,

(fbody select 1 as «поле» from dual^)

А если нужно поумничать, то пишется препроцессор не сложнее cpp,но в начинке у него - весь лисп:

(fse master.*, detail.* from detail M_INNER_JOIN(detail,ref_master);
)

макрос M_INNER_JOIN разворачивает данные из словаря в join и получается:

select master.*, detail.* from detail inner join master on detail.ref_master=master.id

В общем, я понимаю, что никто не воспринимает мой совет поступать так. Типо, это недостаточно заумно. Но мне просто смешно слушать ваши рассуждения, о том, как можно один синтаксис представить другим. Можно-то оно можно, но НА-ХРЕ-НА?

В PHP HTML выглядит точно как HTML. Поэтому, на PHP будут писать сайты и дальше, а на Хаскеле их будут писать только полтора задрота.
Тупо из-за снижения производительности труда. До тех пор, пока не будет сделано что-то типа PHP, где HTML передаётся Verbatim.

Если ты 8x5 в неделю копипастишь SQL-запросы из примеров в мануале, то очень жаль. И да, HTML в Haskell выглядит в точности как HTML.

> И да, HTML в Haskell выглядит в точности как HTML.
Вы с Miguelem определитесь, он выглядит в точности или почти в точности?

8x5 в неделю копипастишь SQL-запросы

Толсто.

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

Вы с Miguelem определитесь, он выглядит в точности или почти в точности?

Hamlet строгое надмножество html. Не исключаю что Мигель с ним не знаком или видел его в те времена когда он выглядел «почти как html».

Толсто.

Именно.

я думаю тебе лучше не касаться тем, связанных с веб-разработкой

Я немного участвовал в проекте symbolicweb. Там использовался parenscript, моя задача была сделать видгеты. Там нужно было как раз брать готовый код html и шаблонизировать его, чтобы порождать соответствующие куски из лиспа. И именно тогда у меня созрело убеждение, что прямые цитаты из html почти всегда лучше, чем обёрнутые в скобочки.

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

Например,

(let1 fld-list '(a b c)
  (fse ~~`("," ,@fld-list)) from foo;
     )

select a,b,c from foo;

> прямые цитаты из html почти всегда лучше, чем обёрнутые в скобочки

Естественно, но в том же PHP всё больше используют шаблоны. Сама идея совмещения разметки с логикой, изначально реализованная в php/jsp/asp/т.п. оказалась неудачной. Поэтому данное свойство PHP уже давно не является каким-либо реальным преимуществом. И не может служить обоснованием того, почему тот же Haskell хуже подходит для веб-разработки, чем PHP (для этого есть другие причины). Кстати, в этой связи упомянутый Hamlet выглядит вещью довольно бесполезной и надуманной и годится только для демонстрации некоторых заманчивых свойств Haskell.

Hamlet строгое надмножество html

В принципе, зачЁт. Только я не понял одного- можно ли инлайнить эти шаблоны прямо в исходник Хаскеля? Я-то могу инлайнить SQL (и, потенциально, любой другой язык) прямо в лисповый код:

(defun foo ()
  (fse 1 from dual;
     ))

Именно.

Не знаю, на что ты намекаешь. Я NIH синдромом не страдаю. Если есть где скопипастить - я это делаю и это экономит много времени. Кроме того, иногда по требованию заказчкика/начальства нельзя помещать в продукт код на лиспе. Кроме того, бывает коллективная разработка с людьми, не знающими лиспа.

Кроме того, всякие «слои поверх», как правило, упускают некоторые нюансы. В случае с SQL таких нюансов очень много и они меняются вместе с версиями сервера.

Кроме того, в случае SQL, есть ещё хранимые процедуры. Есть ли у Хаскеля слой поверх языка хранимых процедур?

И вообще, зачем мне нужно тебя в чём-то убеждать? Время, когда я любил программирование, прошло, теперь это для меня - просто ремесло.

Хочешь ломать мозг об всякие «слои поверх» - ломай. Это твой мозг.