Рекурсивная обработка списков

[levgem]

В руби и в прочие ООП языки усиленно тащат всё подряд, называя это ФП.

Например, в руби есть удобный набор методов на массивах вида each, map и т.п. С ними удобно делать вещи вида:

array2 = array1.map {|i| i*i }
Однако «в реальной жизни» иногда всё бывает немного сложнее и тут понимаешь, насколько более удобен вариант, возможный в эрланге.

Comments

[levgem]

Я не понял, почему непонятно.

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

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

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

Попытка притащить за уши zipWith3 сюда ничем не отличается от попытки приделать паттерн визитор с паттерном фасад для этой задачи.

[lomeo]

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

Далее, zipWith3 - стандартный способ работы с соседними элементами в Haskell.

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

Ну или кинь результат применения функции к списку из item-ов с id 1,2 и 3.

[levgem]

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

[lomeo]

Я не просил помощи :-)

А ты не ответил на вопрос.

[levgem]

https://gist.github.com/4164019

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

[lomeo]

Спасибо! Теперь я понял, что начальный zip3 был правильным решением :-)

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

Для Erlang возможно.

В Haskell здесь только одно место доп. аллокации: то, где ++. Однако, тут же рядом в zip3 стоит декомпозиция по конструктору, который собран в ++, и срабатывает оптимизация, которая называется call-pattern specialisation. Поэтому промежуточный список не будет собран.

Это легко проверить, если заменить ++ на strict версию.

Мало того. В Haskell может быть и исходный и результирующий списки не будут собраны.

[levgem]

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

Зачем менять понятную и оплачиваемую джаву на непредсказуемый в своём поведении хаскель (за который платят 60 тыс рублей в месяц) и продолжать решать инфраструктурные задачи вместо бизнес-задач мне непонятно.

[lomeo]

zip3 - идиоматическое решение в Haskell для соседних элементов.

Второй параграф вообще к чему? Ты написал:

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

Тебе показали, что в некоторых языках это не так. Мало того вот это

Есть функция zipWith3 (erlang lists:zipwith3/4). Она дизайнилась под склеивание трех выровненных списков.

для Haskell просто неверно. Там zipN дизайнились не для выровненных списков.

Вот и всё. Срачик про непредсказуемость и инфраструктурные задачи неинтересен.