Comments 14
Функции в ФП — это объекты первого класса, которые передаются как аргументы, могут быть возвращены из других функций и храниться в переменных.
ошибочка. в хаскеле переменных нет.
ой(
Извиняюсь за неточность в предоставленной информации
А куда они делись-то?
Почему в математике в формуле f(x) = x + 5 переменная x так и называется - "переменная", а в Хаскеле в аналогичном определении f x = x + 5 для переменной x требуется какое-то другое название?
Вот чего в Хаскеле и правда как бы нет - так это изменяемых переменных (но вообще-то нельзя забывать про IORef, MVar и пр.)
Я вот смотрю у вас списки через монады реализуются, а как обстоят дела с массивами и хеш-таблицами?
Как раз списки через монады и не реализуются. Список является монадой, но это не то же самое.
Массив напрямую в ФП не реализуется никак, но будучи реализованным нативно - представляется в ФП без особых проблем. Всего-то нужна функция-оператор, получающая элемент по индексу. Хеш-таблицы же без проблем делаются на основе массивов. Но это всё касается иммутабельных массивов и хеш-таблиц.
Мутабельным массивам и хеш-таблицам требуется монада ST либо IO.
Есть 2 подхода. 1) Идеологически чистый, т.е. делать всё на функциональных типах, по сути делать Map на бинарном дереве c логарифмической скоростью доступа, сделанным с помощью относительно простого алгебраического типа данных data Map k v = EmptyMap | Node k v (Map k v) (Map k v). 2) Не идеалогический HashMap, чуть более быстрый, использующий низкоуровневые примитивы, с массивами написаными на Си, но обёрнутыми в библиотечную апишку так, чтобы со стороны пользователя всё выглядело неоличимо от идеологически верного Map.
Массивы в чистом виде конечно есть, но по возможности стараются обходится без них. Вместо них используют либо связанный список либо Map. Считается, что использование массива напрямую небезопасно.
А в местах, где производительность совсем критична всегда можно вызвать функцию, написанную на чистом си, и творить внутри неё что угодно на своё усмотрение.
Массивы ST вполне безопасны, просто неудобны, и многие задачи, которые мы привыкли решать массивами, на самом деле могут обойтись без них.
Не идеалогический HashMap, чуть более быстрый, использующий низкоуровневые примитивы, с массивами написаными на Си
Это не так. GHC предоставляет достаточно низкоуровневых примитивов, чтобы писать на C вообще не нужно было.
Конечно, какая-то часть этих примитивов в итоге реализована в run-time system через сишку, но и условный аллокатор памяти для чистого кода реализован тоже через сишку, поэтому говорить «для мутабельности и массивов нужно C» смысла нет.
Считается, что использование массива напрямую небезопасно.
Кто считает?
Небезопасно обращаться по индексу через unsafeRead / unsafeWrite у условного Data.Vector, но это и в других языках небезопасно, а тут зависимые типы нас рано или поздно в итоге спасут.
А в местах, где производительность совсем критична всегда можно вызвать функцию, написанную на чистом си, и творить внутри неё что угодно на своё усмотрение.
Только почти всегда не нужно. На хаскеле не сильно сложно писать код, который будет на уровне C по производительности. Разве что, если вам нужно прямо дёргать SIMD-интринсики (но тогда вы не на С пишете), или если у вас какие-то хитрые хаки с памятью (но я не могу сходу такое придумать, что при этом не было бы UB в С).
У вас как-то получается "нет монад - нет Хаскелла". Обычно в учебниках и пособиях идут от функтора, к аппликативу и потом уж монада.
Если бы я 15 лет не учил студентов хаскелю и не написал бы сам когда-то для них книжку, я бы ничего не понял. Ни крышесносящих особенностей хаскеля, ни красоты его построений в тексте, к сожалению, нет. А жаль. Читатель, возьми (неупомянутую в списке литературы) книжку Мирана Липовачи и Изучай Haskell во имя добра!
Книга "Изучай Haskell во имя добра!" у меня есть. Она скучная и не интересная.
Однако, есть множество задач, которые непонятно как за них взяться, а вот с чистым ФП очень даже получается. Пусть даже и с помощью LLM чтобы не мучать мозг синтаксисом академического языка. Накидал на хаскеле (LLM напишет, главное, прочитать), докрутил как удобно и переводим на тот язык который на проде. Для целей проектирования удобно.
Функциональное программирование и программирование на Haskell