Comments 24
Только не
head, а car, и не tail, а cdr :)
Для обозначения списков будем использовать нотацию, похожую на Haskell: x:xs
При чем тут lisp?
Ну при всём :) Всё-таки, устоявшаяся нотация уже.
В Haskell?
сar и cdr это тяжелое наследие лиспа, причем нифига не семантичное, в отличии от head и tail
c*r, чтобы были семантичны производные конструкции — caddr, cadar и т.п.
с head и tail такое будет неинтуитивно
с head и tail такое будет неинтуитивно
А
c*r интуитивно? С таким же успехом нынче можно назвать эти функции zxz и zyz. Будет удобно писать zxxyxxz.При работе с любым языком программирования, какую-то часть информации так или иначе придётся тупо заучить.
А потом уже опираться на выученное.
В лиспе надо просто запомнить CAR, CDR, зато после запоминания это даёт возможность сжимать цепочку вызовов этих функций.
Где-то используется head/tail — это легче запомнить, зато возможности сжатия нет.
А потом уже опираться на выученное.
В лиспе надо просто запомнить CAR, CDR, зато после запоминания это даёт возможность сжимать цепочку вызовов этих функций.
Где-то используется head/tail — это легче запомнить, зато возможности сжатия нет.
Ну вот я, например, привык к функциями ffirst, fnext, nfirst, nnext. Названия легко запомнить (не заучить), они обладают вполне очевидным смыслом. И Вы действительно считаете, что
Но самое смешное, что я эти функции почти не использую. Ну просто не надо. А про всякие
Вы не задумывались, что надобность в таких функциях явно не украшает язык?
c*r лучше?Но самое смешное, что я эти функции почти не использую. Ну просто не надо. А про всякие
caaadr я просто молчу.Вы не задумывались, что надобность в таких функциях явно не украшает язык?
Полезно посмотреть бы на зависимость съеденной памяти от длины списка из nil-ов.
Хотя бы на нескольких длинах: 1000, 10 000, 100 000, 1 000 000, 10 000 000.
Чем чёрт не шутит, представление структур данных функциями может оказаться практичным инструментом.
Хотя бы на нескольких длинах: 1000, 10 000, 100 000, 1 000 000, 10 000 000.
Чем чёрт не шутит, представление структур данных функциями может оказаться практичным инструментом.
Раз уж в Haskell стиле, то не reduce, а foldl/foldr. А еще, для полноты картины, полезно поупражняться и реализовать map/filter через foldl.
Тут больше и интереснее. Практического смысла, правда, никакого.
Sign up to leave a comment.
Связные списки в функциональном стиле