История изменений

поддержу Crocodoom. Есть учебник под рукой, недавно читал, поэтому могу дать ссылку прямо на страницу, Graham Hutton, Programming in Haskell, 2nd edition, стр 79 имеет такое предложение:

More generally, the behaviour of foldr can be summarised as follows:

foldr (#) v [x0,x1,...,xn] = x0 # (x1 # (... (xn # v)...))

так же об этом есть упоминание на стр. 202 той же книги (evaluating of foldr... performed from right-to-left)

Т.е. такое понимание как минимум встречается в литературе. Правда, такого (про конструкторы) я не встечал объяснения как дал крокодум.
На сколько я себе представлял дело в ассоциативности, как в цитате выше из хаттона. В подтверждение что такое представление существует не только у хаттона, могу привести цитату из хаскель-вики

https://wiki.haskell.org/Fold

either by recursively combining the first element with the results of combining the rest (called a right fold)

т.е. решение которое дал крокодум соотвествует этим объяснениям.

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

Что до аргумента про свёртку (обычного) дерева, там можно реализовывать фолдр по разному. Но в целом кажется что не каждая реализация будет соотвествовать семантике фолдр (то есть правоассоциативности). Кажется что другие названия для свёрток в случае если они не точно соотвесвтуют foldr были бы более кстати. Но я не готов тут спорить, может они кстати и существуют.

Что до аргумента «делают меньше ошибок на хаскеле» - так до этого (перепутат порядок соединения внутри фолда) ещё вообще то нужно дойти. Т..е я имею ввиду до этоо момента можно сделать миллион ошибок от которых защищает система типов (вот как ТС), а перепутать то что перепутывается в хаскеле ни в одном другом языке (ну кроме агды/идриса/кока и т.п) ничего помешать не может. Странно что ты это записываешь себе в аргументы.

поддержу Crocodoom. Есть учебник под рукой, недавно читал, поэтому могу дать ссылку прямо на страницу, Graham Hutton, Programming in Haskell, 2nd edition, стр 79 имеет такое предложение:

More generally, the behaviour of foldr can be summarised as follows:

foldr (#) v [x0,x1,...,xn] = x0 # (x1 # (... (xn # v)...))

так же об этом есть упоминание на стр. 202 той же книги (evaluating of foldr... performed from right-to-left)

Правда, такого (про конструкторы) я не встечал объяснения как дал крокодум.

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

https://wiki.haskell.org/Fold

either by recursively combining the first element with the results of combining the rest (called a right fold)

т.е. решение которое дал крокодум соотвествует этим объяснениям.

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

Что до аргумента про свёртку (обычного) дерева, там можно реализовывать фолдр по разному. Но в целом кажется что не каждая реализация будет соотвествовать семантике фолдр (то есть правоассоциативности). Кажется что другие названия для свёрток в случае если они не точно соотвесвтуют foldr были бы более кстати. Но я не готов тут спорить, может они кстати и существуют.

Что до аргумента «делают меньше ошибок на хаскеле» - так до этого (перепутат порядок соединения внутри фолда) ещё вообще то нужно дойти. Т..е я имею ввиду до этоо момента можно сделать миллион ошибок от которых защищает система типов (вот как ТС), а перепутать то что перепутывается в хаскеле ни в одном другом языке (ну кроме агды/идриса/кока и т.п) ничего помешать не может. Странно что ты это записываешь себе в аргументы.