> сочитал

к логопеду, быдло..

> ласпа

К логопеду, быдло!

> списки как в лиспе(переменные разных Заранее благодарен.

К логопеду, быдло!

На ЛОРе в группе "Development" на вопрос "Какой язык мне лучше всего выучить первым?" неизменно отвечают "русский".

http://liskell.org/

>сочитал черты хаскела и ласпа?

Конечно к логопеду

По теме - Хаскелл сочетает в себе черты Хаскелля и Лиспа - хочешь макросов - копай в сторону Template Haskell. Простой синтаксис - не юзай продвинутые фичи и он будет настолько прост насколько это нужно ставь везде скобки и операторы пользуй в префиксной форме типа ((+) 2 3) (незнаю уж зачем тебе это надо). Списки вроде и так как в Лиспе, переменные разных типов - копай в сторону Data.Dynamics.

>> Списки вроде и так как в Лиспе,

Нифига, хаскель не даст сделать такое: (list "a" 'b 3). В хаскеле в список можно пихать только однотипные элементы.

>> ставь везде скобки и операторы пользуй в префиксной форме

Это будет закос под лисп, но ни как не S-exp.

>> Простой синтаксис - не юзай продвинутые фичи и он будет настолько прост насколько это нужно

А "продвинутые" это какие?

> Отсюда вопрос: нет ли такого языка который бы сочитал черты хаскела и ласпа?

1) К логопеду

2) Template Haskell

> Списки вроде и так как в Лиспе

Список в Хаскелле - это односвязный список, в Лиспе же "список" - двоичное дерево. Синтаксического сахара для двоичных деревьев в Хаскелле не предусмотренно.

Ещё есть какое-то недоделанное хаскелолиспное говнецо http://dslengine.sf.net/

>В хаскеле в список можно пихать только однотипные элементы.
4.2

data ShowBox = forall s. Show s => SB s

heteroList :: [ShowBox]
heteroList = [SB (), SB 5, SB True]

man Existentially quantified types

Сначала создадим себе проблем, а потом их через жопу решим - это haskell way! И каким боком твои экзистенциальные костыли имеют отношение к спискам в лиспе? Зачем плодить сущности если можно '(() 5 #t) ?

>говнецо

не обижай профессора ;)

Ну так ведь объективно говнецо.

>Сначала создадим себе проблем, а потом их через жопу решим - это haskell way! И каким боком твои экзистенциальные костыли имеют отношение к спискам в лиспе? Зачем плодить сущности если можно '(() 5 #t) ?

Ибо контроль типов должен быть. Если контроль типов не нужен то можно конечно - например все сконвертить в Dynamic и можно совать в один список, только потом контроль типов на тебя ложится. Я делаю гетерогенные списки только там где мне реально нужны гетерогенные, а чаще всего обычных хватает. А из за того что в Лиспе по умолчанию все списки гетерогенные там где надо и там где нет он и выходит таким тормозом, потому как если ты тип на стадии компиляции не знаешь то и не соптимизируешь...

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

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

В общем CH4 + H2O :)

> Ну так ведь объективно говнецо.

Ну так доделай.

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

ps: хотя я и сам не в восторге от этих SB

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

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

>> Да не имеют

>> В Лиспе же они за счет динамической типизации гетерогенные, поэтому его труднее оптимизировать.

Если человек идиотЮ то это надолго (с). Ты уж сам таки определись имеют таки гетерогенные списки отношение к динамической типизации или нет. BTW в лиспе тебе никто не мешает явно указывать тип объектов и списки от этого не становятся гомогенными.

>Если человек идиотЮ то это надолго (с). Ты уж сам таки определись имеют таки гетерогенные списки отношение к динамической типизации или нет. BTW в лиспе тебе никто не мешает явно указывать тип объектов и списки от этого не становятся гомогенными.

Ты пробовал вообще читать что я пишу? Сам сначала заявил что в хаскелле нет гетерогенных списков, а теперь вообще бред гонишь. Я говорю что в Лиспе списки гетерогенные из-за динамической типизации, в хаскелле же ты можешь выбрать либо статическую типизацию и existentially quantified types или динамическую через Dynamic для их реализации. А то что ты в лиспе явно уажешь типы не сделает типизацию статической. Учи матчасть на предмет статическая / динамическая типизация и явная / неявная типизация и втыкай почему эти понятия ортогональны.

Нет дружок это ты гонишь. Давай я тебя ткну в твои же слова:

С утверждением что динамическая типизация не имеет отношения к гетеро/гомо-секс^Wгенности списков ты согласился полностью, так? Так! Потом, ты мне впарил про то, что в лиспе списки гетерогенные потому что там типизация динамическая, так? Так! Логика наблюдается? Нет!

В хаскеле же списки гомогенные по определению! И от того, что ты можешь при помощи извращенного мозгоебизма с системой типов напихать в список однотипных контейнерных объектов с различным содержанием они гетерогенными не становяться. То что ты скопипастил из хасельного wiki - это гомогенный список над контейнерными типом ShowBox. Тип у всех элементов один - ShowBox: heteroList :: [ShowBox]

>> Учи матчасть на предмет статическая / динамическая типизация и явная / неявная типизация и втыкай почему эти понятия ортогональны.

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

Русского языка непонимаешь да? >С утверждением что динамическая типизация не имеет отношения к гетеро/гомо-секс^Wгенности списков ты согласился?

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

>Потом, ты мне впарил про то, что в лиспе списки гетерогенные потому что там типизация динамическая, так? Так!

Наоборот там списки гетерогенные потому что типизация динамическая.

>Логика наблюдается? Нет!

Это у тебя проблемы с логикой.

>В хаскеле же списки гомогенные по определению! И от того, что ты можешь при помощи извращенного мозгоебизма с системой типов напихать в список однотипных контейнерных объектов с различным содержанием они гетерогенными не становяться. То что ты скопипастил из хасельного wiki - это гомогенный список над контейнерными типом ShowBox. Тип у всех элементов один - ShowBox: heteroList :: [ShowBox]

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

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

Ха ха - "тип привязан к символу" Если ты достал что то из списка в переменную которой назначен тип, то это называется cast, который надо проверить и упасть если тип оказался не тем, причем делать это надо в рантайме, ну и где тут оптимизация?

>Конкретно хотелось бы: простой синтаксис как у лиспа, возможность легко изменять язык (что то типа макросов лиспа), ленивость, сопоставление с образцом, списки как в лиспе

Qi? http://www.lambdassociates.org/

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

А на кой мне? Из говна пулю не вылепишь. Я лучше Template Haskell доделаю.

Да, как же я мог забыть про Qi?!? Самое то, что доктор прописал.

>> Не так - динамическая типизация - это один из способов _реализовать_ гетерогенные списки.

Гражданин, на прошлом допросе вы давали другие показания.

>> Да пример я скопипастил с вики и что я теперь должен посыпать голову пеплом? Только тролль приводит такие утверждения когда ему нечего сказать.

Ну можешь конечно посыпать, я не против. Только скопипастил ты его без особого понимания. Разговор шел о чем? Что в хаскельный список нельзя засунуть разнотипные объекты - это раз, и поэтому он не похож на лимповый список (ты утверждал что можно, ссылался на 4.2 и проч.) - это два. С точки зрения системы типов как бы ты ни фокусничал с типами, тип [ShowBox] это тоже самое, что [a] безотносительно внутренней структуры типа a.

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

Ну да в хаскеле можно много чего _сэмулировать_, только делается это все через задницу. Туда же дет и производительность.

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

А пример без кастов слабо придумать?

>Ну можешь конечно посыпать, я не против. Только скопипастил ты его без особого понимания. Разговор шел о чем? Что в хаскельный список нельзя засунуть разнотипные объекты - это раз, и поэтому он не похож на лимповый список (ты утверждал что можно, ссылался на 4.2 и проч.) - это два. С точки зрения системы типов как бы ты ни фокусничал с типами, тип [ShowBox] это тоже самое, что [a] безотносительно внутренней структуры типа a.

Ну это как посмотреть - да засунуть нельзя (но в тип засунуть можно и вынуть потом (например Dynamic)), поэтому можно все те же задачи решать.

>Ну да в хаскеле можно много чего _сэмулировать_, только делается это все через задницу. Туда же дет и производительность.

4.2

>А пример без кастов слабо придумать?

А чем этот плох?

>> А чем этот плох?

А чем хорош?

>> поэтому можно все те же задачи решать.

Можно, но через зад. Ты же не будешь спорить, что ООП на ассемблере тоже можно? Но какими усилиями! То же и здесь. Вместо того, что максимально абстрагироваться от языка, нужно постоянно на его "фичи".

>> 4.2

Ну типа ответ не мальчика, но мужа. Тыкать в unsafe-bla-bla не буду, т.к. это не Ъ, но по секрету скажу, что именно такими тяжкими преступлениями против человечества в хаскеле и достигается производительность :)

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

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

>Ну типа ответ не мальчика, но мужа. Тыкать в unsafe-bla-bla не буду, т.к. это не Ъ, но по секрету скажу, что именно такими тяжкими преступлениями против человечества в хаскеле и достигается производительность :)

Где тут unsafe? Опять троллишь?

>Ну да в хаскеле можно много чего _сэмулировать_

можно. а нужно ли ?

>только делается это все через задницу

в LISP'е возможностей сделать всё через задницу намного больше. разве нет ?

>Туда же дет и производительность

а в LISP'е она куда идёт ? я ещё понимаю подобный наезд от поклонника C, или хотя бы *ML - но здесь-то полемика Haskell vs LISP, какая к собачьим монахам производительность ?

>> Где тут unsafe? Опять троллишь?

А я и не говорил про "тут", я говорил про производительность вообще. Например, (++) имеет сложность O(n), хотя можно и O(1), но без unsafe* это не получится.

>> Ты вообще пробовал что нибудь писать или только теоретизировать горазд?

Конечно же нет! А ты как думал?

>в LISP'е возможностей сделать всё через задницу намного больше. разве нет ?

За что я не люблю Лисп - за то что там гораздо проще выстрелить себе в ногу.

>а в LISP'е она куда идёт ? я ещё понимаю подобный наезд от поклонника C, или хотя бы *ML - но здесь-то полемика Haskell vs LISP, какая к собачьим монахам производительность ?

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

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ghc&...

>> в LISP'е возможностей сделать всё через задницу намного больше. разве нет ?

Там _вообще_ больше возможностей, в т.ч. и через задницу. В хаскеле же одна - через задницу :)

>> а в LISP'е она куда идёт ?

По правильному пути конечно же :) На хаскеле далеко не все можно реализовать со сложностью O(1) (точнее, практически ничего нельзя)

>Хаскелл то заметно побыстрее будет, и памяти гораздо меньше жрет

спорно на самом деле. как по мне ни тот ни другой для высокопроизводительных вычислений всё равно не подходят - разве что в условиях хорошо распареллеливаемых задач ФП может быть очень полезно, ну дык его на необходимом уровне в принципе и CL и Haskell поддерживают. сколько памяти жрёт CL я не знаю, но Haskell в этой области точно не подарок. парафия обоих языков прежде всего - решение сложных архитектурных задач, простота создания и поддержки высокоуровневого кода. такова моя имха

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

Честно говоря если не считать startup то выдающихся приемуществ в скорости нет. Однако sbcl не самый быстрый в этом плане, cmucl гораздо быстрее. Ну память - это да...

>Там _вообще_ больше возможностей, в т.ч. и через задницу

бритвы Оккама на лисперов нет

>В хаскеле же одна - через задницу :)

не, ну это чистой воды 4.2

>По правильному пути конечно же :) На хаскеле далеко не все можно реализовать со сложностью O(1) (точнее, практически ничего нельзя)

практика показывает что это совсем не так страшно как звучит. вот, например, http://www.cs.colostate.edu/~anderson/languages/, http://alberrto.googlepages.com/gslhaskell. во втором используется тот самый страшный и ужасный unsafePerformIO, но интерфейс при этом вполне себе функциональный

>По правильному пути конечно же :) На хаскеле далеко не все можно реализовать со сложностью O(1) (точнее, практически ничего нельзя)

Это 4.2, если тебе надо соединять юзай например Data.Sequence оно за O(log n) соединяется и вполне себе safe, а списки они не для этого. В лиспе списки тоже не за O(1) соединяются. Если нужно за O(1) соединять пользуйся IArray они безопасны + чтение по индексу за O(1).

fixed

> какая к собачьим монадам производительность ?

>> В лиспе списки тоже не за O(1) соединяются

Соеденяются, очень даже хорошо соединяются: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.2

>> Если нужно за O(1) соединять пользуйся IArray они безопасны + чтение по индексу за O(1).

А, ну-да... Но нужен то список а не массив :)

>А, ну-да... Но нужен то список а не массив :)

>Соеденяются, очень даже хорошо соединяются: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.2

Вызывающее 4.2 - во-первых - это не список, во-вторых, оно не соединяется за О(1), в-третьих, все что оно делает за О(1), Data.Sequence тоже за О(1) делает.

>> Вызывающее 4.2 - во-первых - это не список,

Во-первых это список, во-во вторых соединяется за O(1), в третьих (><) делает соединений за O(logN), а то, что ты назвал 4.2 делает тоже за O(1):

1) Делает (set-cdr! (жопа первого списка) (голова второго списка))

2) Апдейтит front-ptr и rear-ptr

Все операции O(1), так что Data.Sequence можешь сернуть в трубочку :)) Ну что, будем дальше ваньку валять, или в конце-концов согласимся, что без unsafe* хаскель не справится с этой задачей?

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

Блин ты тут опять теплое с мягким мешаешь - Ежели небезопасно так и в Хаскелле можно делать, ты считаешь что если в Схема небезопасна по умолчанию это ее плюс? Вот соеденишь ты так списки, а потом возьмешь и из изначального списка удалишь элемент, и из соединенного тоже удалится, Это разве хорошо? Это сайдэффект. Такие вещи должны контролироватся и не вылезать наружу иначе утекание абстракций будет, чем ваши Лиспы страдают постоянно...

>Формально хаскель такой же функциональный как и лисп, только в хаскеле всю императивщину упрятали с глаз долой, что не есть гуд. Зато на каждом заборе написано какой хаскель девственно чистый :)

Чеж Лисп ваш который все с сайдэффектами делает медленный то такой тогда?

>> иначе утекание абстракций будет, чем ваши Лиспы страдают постоянно...

Что будет?? Это такой новый термин "утекание абстракций"?

>> Вот соеденишь ты так списки, а потом возьмешь и из изначального списка удалишь элемент, и из соединенного тоже удалится

Ну ясен пень удалится. И чего? Ты как разработчик об этом не догадывался?

>> Ежели небезопасно так и в Хаскелле можно делать, ты считаешь что если в Схема небезопасна по умолчанию это ее плюс?

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

>> Чеж Лисп ваш который все с сайдэффектами делает медленный то такой тогда?

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

>Чеж хаскель ваш который такой офигенный до сих пор в жопе болтается и никак не дорастет хотябы до уровня лиспа по используемости?

А че на лиспе написали? На Хаскелле хотя бы Рugs и xmonad - это навскидку...

http://www.haskell.org/haskellwiki/Haskell_in_industry

* Deutsche Bank Equity Proprietary Trading, Directional Credit Trading

The Directional Credit Trading group uses Haskell as the primary implementation language for all its software infrastructure.

Там наверное дураки работают которые не знают про Лисп?

>Что будет?? Это такой новый термин "утекание абстракций"?

http://en.wikipedia.org/wiki/Leaky_abstraction

>Ну ясен пень удалится. И чего? Ты как разработчик об этом не дыгадывался?

Это сайдэффект, который может легко выйти боком, и надо будет дебажить.

>Не-а, я считаю, что орать, что хаскель безопасен и иметь в нем небезопасный unsafeWrite и проч. это очень серьезный минус. В первую очередь из-за того, что каждая первая книжка/статья об этом говорит. Это говорит о том, что кто-то выдает желаемое за действительное.

Хаскелл допускает сайдэффекты, просто они помечены как unsafe, например unsafe функции для работы с массивами не делают boundary-check - зато ты знаешь, что тогда нужно очень хорошо проверять код чтобы он не вышел за пределы.

>> Хаскелл допускает сайдэффекты, просто они помечены как unsafe, например unsafe функции для работы с массивами не делают boundary-check - зато ты знаешь, что тогда нужно очень хорошо проверять код чтобы он не вышел за пределы.

Ну и в схеме такие функции имеют специальное обозначение - set!, set-car! и т.д. у всех "!". Теперь схема такая же безопасная как хаскель?

>> Это сайдэффект, который может легко выйти боком, и надо будет дебажить.

Может. А может и не выйти. Если обезьяне дать гранату тоже много чего может выйти.

Я одного не пойму: почему для хаскеля unsafe - это ничего страшного, только нужно "очень хорошо проверять код", а для всех остальных уголовная статья.