LINUX.ORG.RU

[Haskell] Рудименты

 


0

1

(Хотел поместить тему в Talks, но LOR выдаёт 403.)

В процессе чтения LYAH и Typeclassopedia постоянно натыкался на фразы типа «следовало бы сделать так-то, но по историческим причинам реализовано так-то». Особенно в Typeclassopedia такого много. Например, все монады должны по идее являться также функторами и Applicative, но из-за того, что монады появились в языке раньше и бла-бла-бла, монады официально не являются ни Functor, ни Applicative и, как следствие, реализуют уже реализованное (напр. return — это pure из Applicative, liftM — ничто иное, как fmap из Functor. То есть можно было просто «унаследовать» их, но по историческим причинам этого не делается). Там ещё много подобных примеров, не вижу смысла всех перечислять.

Мне вот интересно, почему разработчики Хаскеля такие консервативные? Почему они не хотят сбросить с себя груз истории и реализовать всё как следует?

Слышал, что готовится замена стандарту Haskell 98. Кто знает, там в этом отношении что-то будут менять или опять оставят в дань истории?


>Мне вот интересно, почему разработчики Хаскеля такие консервативные? Почему они не хотят сбросить с себя груз истории и реализовать всё как следует?

Дань обратной совместимости. Ломать написанный за 10 лет код на хаскелле-98 ради избавления от мелких неудобств — идея не очень удачная. Существует проект http://www.haskell.org/haskellwiki/The_Other_Prelude, который как раз этим и занимается. Только продвижения там особого нету — есть более насущные проблемы. Вон, ад зависимостей mtl на днях починили, куда большая польза сообществу.

Слышал, что готовится замена стандарту Haskell 98. Кто знает, там в этом отношении что-то будут менять или опять оставят в дань истории?

В ближайшие несколько лет изменений в стандарте не предвидится. Если сильно припечёт — напишут свою реализацию, как это сделали в Numeric Prelude. Или, может, сами напишете? ;-)

anonymous
()
Ответ на: комментарий от anonymous

Дань обратной совместимости.

Но ведь, по-моему, совместимость можно оставить. К примеру, можно оставить liftM, но просто как синоним fmap. Или там более глубокие проблемы?

За ссылку спасибо и вам и jtootf, почитаю.

toady2
() автор топика
Ответ на: комментарий от vasilenko

В том-то и дело! Лично я воспринимаю Haskell больше как академический, нежели прикладной язык. (Что бы там не говорили, но абсолютная чистота языка делает связь с внешним миром костылём и довольно монструозным. OCaml, Erlang и т.п. языки, на мой взгляд, более практичны, хотя и не так красивы.) А если язык академический, то он IMHO обязан быть очень строгим, красивым и правильно устроеным, пускай даже в ущерб совместимости.

toady2
() автор топика
Ответ на: комментарий от toady2

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

Не согласен =). Раньше, да. Когда ввод/вывод делался(или хотел делаться?) путем написания функции main :: [Input] -> [Output].

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

OCaml, Erlang и т.п. языки, на мой взгляд, более практичны, хотя и не так красивы.)

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

Waterlaz ★★★★★
()
Ответ на: комментарий от vasilenko

>Просто хаскель не особенно стремится быть практичным.

Мне кажется, что когда-то это было так. Сейчас, скорее нет. Когда-то и avoid success at all cost было правдой =).

Waterlaz ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.