Злые языки утверждают, что функциональные языки программирования — «языки для написания факториалов». Чаще всего так определяют язык Haskell, мы же начнем с того функционального языка, который сильно повлиял и на Haskell, и на подмножество средств для функционального программирования многих других языков — язык Scheme. По-крайней мере, map и for-each, filter и reduce, а так же apply и eval пришли в наши любимые языки программирования если не именно из Scheme, то в том числе и оттуда.  Рассмотрим некоторые возможные способы записи вычисления факториала. Заодно получится своеобразная ода языку программирования Scheme. Думаю, этот замечательный язык того вполне заслуживает. У меня получилось 10 вариантов записи определений функций, которые можно свести к 3 основным способам вычисления: традиционному линейно-рекурсивному вычислительному процессу, итерации, генерации последовательности чисел с последующей сверткой умножением. Предлагаю рассмотреть эти варианты подробнее. Попутно мы рассмотрим: оптимизацию хвостовой рекурсии, функции высших порядков и метапрограммирование, отложенные вычисления, бесконечные списки, мемоизацию, способ создать статическую переменную в Scheme и гигиенические макросы.  Для экспериментов был использован старый добрый диалект Scheme R5RS и популярный принцип изобразительного искусства «минимум средств — максимум впечатлений». Все примеры на Scheme были подготовлены в среде DrRacket 6.2 в режиме R5RS. Замеры времени выполнения были выполнены в Guile 2.0 в среде ОС OpenSUSE Leap 15. Для начала можно взять рекурсивное определение факториала и просто переписать формулу на Scheme: Получилось определение функции (в терминах Scheme — процедуры, хотя по-сути она является функцией) для вычисления факториала, которое можно увидеть в бесчисленном множестве руководств по программированию, начиная с бессмертной книги Х. Абельсона и Д. Сассмана «Структура и интерпретация компьютерных программ». Читать и понимать этот код можно так: факториал  есть  если , иначе — . Таким образом, этот код соответствует рекурсивному определению факториала, принятому в математике. Единственное, мы не проверяем принадлежность  неотрицательным числам. Будучи рекурсивным, код выше содержит очевидное ограничение на величину : на стеке будут накапливаться данные рекурсивных вызовов, пока  не достигнет 0. Это может вызвать переполнение стека при больших . Как можно снять это ограничение? Надо оптимизировать хвостовую рекурсию: переписать код таким образом, чтобы рекурсивный вызов стал хвостовым (т.е. последним в процедуре). Это позволит интерпретатору Scheme выполнить оптимизацию — заменить рекурсивное вычисление итеративным. Если воспользоваться рекомендациями авторов упомянутой выше книги, можно получить следующее: Этот код является расхожим примером, и, начиная с книги «Структура и интерпретация компьютерных программ», именно на нем обычно объясняют оптимизацию хвостовой рекурсии. Это была классика. Но Scheme — сама гибкость, нельзя ли записать то же самое принципиально иначе? И, желательно, еще короче? Например, согласно записи  сформировать последовательность от  до  (или от  до ) и затем свернуть её умножением? Благо, в Scheme это сделать достаточно просто благодаря встроенной процедуре apply, которая применяет процедуру с произвольным числом аргументов к списку: Scheme славится своим удобством для символьных вычислений в силу «единства кода и данных» (так иногда говорят о языках семейства Лисп). Используем эту особенность: сформируем выражение для вычисления факториала числа , а затем его вычислим: Символ «обратная одиночная кавычка» означает квазицитирование (quasiquotation). Без квазицитирования получение выражение для последующего вычисления можно было бы получить с помощью кода (cons '* (iota n)). Одиночная кавычка (цитирование, quotation) означает, что * надо подставить в выражение именно как имя (символ), а не соответствующее ему значение (здесь — процедуру). Так, при  получим (* 3 2 1). Этот список является выражением на языке Scheme. Его значение может быть выполнено в подходящем окружении, лучше всего — в окружении (interaction-environment), содержащем встроенные процедуры и процедуры, определенные нами в программе. Собственно, это мы и делаем в теле factorial-eval. Scheme поддерживает отложенные вычисления. Haskell, который испытал значительное влияние Scheme, использует ленивую модель вычислений, т.е. не вычисляет значение выражения до тех пор, пока результат этих вычислений не будет востребован. Это позволяет иметь в программах такие своеобразные структуры данных, как бесконечные списки. Если из них брать только часть, необходимую для дальнейших вычислений, программа не будет зацикливаться: Выражение  генерирует бесконечный список целых чисел. Выражение take 4 получает из этого списка 4 первых элемента. Поскольку последующие элементы списка остаются невостребованными, они не вычисляются. На Haskell получение  из бесконечного списка можно записать так: Используя пару форм Scheme delay/force попробуем сделать нечто подобное. Ключевое слово delay создает обещание вычислить значение выражения. Ключевое слово force распоряжается осуществить эти вычисления, полученное значение вычисляется и запоминается. При повторном обращении новых вычислений не производится, а возвращается значение, вычисленное ранее. В языках семейства Лисп списки строятся из пар. Для того, чтобы конструировать бесконечные списки, введем тип «ленивая пара» — пара, в которой первый элемент — вычисленное значение, а второй — обещание вычислить значение. Для этого нам надо дополнить «святую троицу» языков семейства Лисп (cons, car, cdr) их ленивыми версиями:  Конструктор ленивой пары lazy-cons реализован в виде макроса. Это сделано для того, чтобы избежать вычисления значения второго элемента пары при ее создании. Идея состоит в том, чтобы создать бесконечный список значений, а потом взять из него то, которое нужно. Для этого определим ленивую версию процедуры для получения элемента по индексу: Здесь n! и n+1 — имена переменных. В Scheme, по-сравнению с другими языками, существует очень немного символов, которые нельзя использовать в идентификаторах. Обратите внимание, что генератор бесконечного списка generate-factorials не содержит выхода из рекурсии. Тем не менее, он не будет зацикливаться, так как при его вызове будет вычисляться только голова списка, хвост же будет представлен обещанием вычислить значение. Теперь можно определить  как получение -го элемента списка факториалов: Это работает. При этом, если в одной сессии интерпретатора вычислять факториалы различных чисел, то вычисления будут происходить быстрее, чем в строгих версиях, ведь часть значений в ленивом списке будет уже вычислена. Кстати, код на Scheme весьма близок к таковому на Haskell. Так, оператор получения !! примерно соответствует процедуре lazy-list-ref, конструктор списка : соответствует lazy-cons. Соответствует примерно, потому что Haskell, хотя и исповедует ленивую модель вычислений, однако, в отличие от delay/force в Scheme, вычисленные значения не запоминает. Кстати, для повышения производительности можно применить запоминание уже вычисленных значений — мемоизацию. Будем хранить вычисленные значения в ассоциативном списке, в котором ключами будут числа, а значениями — их факториалы. При вызове, просмотрим список на предмет уже вычисленных значений. Если значение присутствует в списке, будем возвращать это сохраненное значение. Если значение в списке отсутствует, будем вычислять его, помещать в список, и только потом возвращать. Чтобы этот список всегда находился при вызываемой функции, а не в глобальном окружении, разместим его в статической переменной: Код вида является принятым в Scheme способом создать процедуру со статической переменной. Принцип такого объявления удобно пояснить на более коротком примере — процедуре, возвращающей число своих вызовов: В одной сессии интерпретатора первый вызов (count) вернет 1, второй — 2, третий — 3 и т.д. Как это работает? Без синтаксического сахара определение count выглядит так: Таким образом, с именем count связана процедура без аргументов (lambda () (set! n (+ n 1)) n), в которую свободно входит n. Получается, что n определена во внешнем окружении по отношению к (lambda () (set! n (+ n 1)) n), что означает, что значение n будет сохраняться между вызовами count. Значение n инициализируется нулем при запуске программы, так как (lambda (n) ...) применяется к аргументу 0. Поэтому n отсутствует в глобальном окружении, но всегда доступно из count. Данная реализация также обещает прирост производительности при неоднократном вычислении факториалов различных чисел в одной сессии интерпретатора.  Разумеется, здесь также возможна оптимизация хвостовой рекурсии: «Зачем эти танцы с бубном?», — может сказать читатель. На императивных языках программирования то же самое пишется просто — через цикл, работает быстро и без лишних затрат памяти. В Scheme есть подмножество для императивного программирования, есть в нем и средство для организации циклов — специальная форма do. Процедура для вычисления факториала, записанная с её помощью, может выглядеть так: Конструкция do — достаточно универсальная, и именно поэтому — не слишком удобочитаемая. Не лучше ли организовать свой собственный цикл в императивном стиле? В этом помогут макросы: Благодаря оптимизации хвостовой рекурсии интерпретатором, получим цикл, к каким мы привыкли в императивных языках программирования. Благодаря оптимизации хвостовой рекурсии, стек расти не будет.  Определение факториала с использованием for: В данном примере выражение (for (i 1 (<= i n) (+ i 1)) (set! product (* product i))) будет сопоставлено с образцом (_ (variable init test step) . body) синтаксического правила. Будут выполнены следующие подстановки: Отсюда, шаблоном синтаксического правила будет сформирован следующий код: Возможен еще один вариант, внешне похожий на императивный цикл for — со встроенной процедурой for-each: Велик и могуч язык Scheme! А что с производительностью? Для замеров производительности воспользуемся GNU Guile — в этой среде можно замерить время вычисления выражения наиболее просто.  Guile работает следующим образом: компилирует исходный текст программы в байт-код, который затем выполняется виртуальной машиной. Это — только одна из реализаций и один из нескольких возможных способов выполнения программы на Scheme, существуют и другие: Racket (использует JIT-компиляцию), Chicken Scheme (использует «честную» интерпретацию или компиляцию в подмножество C) и т.д. Очевидно, что и ограничения, и производительность программ в этих средах могут несколько отличаться. Замеры будем производить при некотором значении . Каким должно быть это ? Таким, с каким наибольшим  смогут «справиться» предложенные варианты. С настройками Guile 2.0 по-умолчанию, на ПК с Intel Core i5 и 4 Гб ОЗУ, меня получилось следующее: Отсюда, тесты производительности выполнялись при . Результаты представлены в таблице ниже, где  — время выполнения,  — время работы сборщика мусора в секундах.
Для всех процедур, кроме ленивых и мемоизованных, указаны наименьшие значения времени выполнения и соответствующее ему время работы сборщика мусора, полученные по итогам трех запусков при .
Для мемоизованных и ленивых процедур указано время выполнения первого вызова, далее — меньшее из трех вызовов. У нас есть 4 варианта, которые могут работать с большими . При  они имеют следующие времена вычисления и сборки мусора: Можно видеть, что при не слишком больших  наиболее быстрым и, одновременно, самым коротким и оказывается первый. Этот же вариант наиболее полно соответствует математическому определению факториала. Вариант с оптимизацией хвостовой рекурсии ему не сильно уступает в производительности. Оба этих варианта являются идиоматическими, рекомендованными авторами языка. Вывод во многом очевиден: если не оговорено иное, подход, являющийся для языка «типовым», является предпочтительным, по-крайней мере, для первой реализации алгоритма или метода. В то же время, язык Scheme позволил написать нам много вариантов реализации вычисления факториала, используя при этом весьма ограниченный набор примитивов (то самое «минимум средств — максимум впечатлений»). Поэтому, несмотря на почтенный возраст и не слишком широкую распространенность, этот язык всё ещё можно рекомендовать для исследовательского программирования: похоже, на нем можно реализовать всё что угодно и каким угодно (и каким удобно) способом. IT