Комментарии 6
Трамплины в Scala — неотъемлемый инструмент для оптимизации рекурсивных вызовов. Их использование не только обеспечивает эффективное управление стеком, но и повышает производительность, делая код более читаемым и легко поддерживаемым в контексте функционального программирования
Извините, но я один вижу что вы написали интерпретатор? Глупый вопрос, а зачем когда на той же jvm есть jsr223, который scripting, ну или на худой конец сама jvm и есть интерпретатор/транслятор байткода. Зачем писать управление стеком и осуществлять интерпретирование? Я молчу про escape analyse, inline... Вывод типов в ast...
Или тут речь про dsl который любят в scala называть алгебрами?
Чтобы не было переполнения обычного стека.
Нет, интерпретатор калькулятора в статье только для примера алгоритма, в котором доступность взаимной множественной рекурсии произвольной вложенности существенно упрощает реализацию.
На мой взгляд, более фундаментальным применением `Eval` является пример про свертку справа: `foldRight` -- так как традиционно в функциональном программировании все непросто обработкой бесконечных последовательностей или преждевременным выходом из цикла: для чистых функций непросто определить аналоги `break/continure`, а бросаться исключениями нехорошо, да и ловить их нужно в строго определенные момент.
Haskell справляется с этим, так как ленив по своей природе, однако Scala -- строгий (strict) язык, и в нем попытка сделать свертку на бесконечной коллекции или писать рекурсию без проверки на то, хвостовая она или нет -- прямой путь к StackOverflow или OutOfMemory.
Представленные в статье `Eval & Cont`, как и другие примеры шаблона "трамплин", как раз и решают описанные выше проблемы через а) отложенные вычисление, б) возможность "пропуска" определенных ветвей вычисления, в) то, что в функциональном смысле никак не снижают "чистоту" методов, в которых используются. При этом, поскольку мы все еще пишем на Scala и (например) все еще интерпретируем в байткод, нам по-прежнему доступны и инлайнинг, и escape analysis, и другие бонусы JVM.
P.S.: Алгебра это не просто синоним dsl, это список операций над некоторым множеством элементов, результатом которых является самое это множество: https://stackoverflow.com/a/16022059/790763
Интересный пост, спасибо
Давно не читал такой занятной каши.
Попробуем переписать то же самое, но «функционально» — без изменяемого состояния
Блин, первый пример кода уже написан функционально, там нет никакого изменяемого состояния. В этом месте для понимания логики статьи было бы полезно сначала какую-нибудь понятную конечную цель указать, а не переписать на ровном месте. Ладно, я понял, что автор хочет показать, что монады - это круто, на примере Optional (плохой пример, ненаглядный).
Поехали дальше. Вставка
Так, мы можем заменить использование `.flatMap` в одном из наших первых примеров на использование `match`
вообще никак не связана с предыдущим заходом на монады, и для дальнейшей логики статьи не нужна.
И завершение главы
На основе вышесказанного дадим своё простое определение эффекта
никак не основывается на вышесказанном (вообще ни одного примера "эффекта" не было продемонстрировано), и само определение ни разу не добавляет понятности.
Логичность и последовательность изложения во второй главе также хромают. Непонятно к чему упомянув свёртку, к середине статьи автор таки произносит волшебное слово "хвостовая рекурсия", которое каждый функциональщик изучает раньше, чем слова "монада" и "функтор". Но, чёрт, оказывается, что хвостовая рекурсия - "не всегда это так просто", поэтому давайте перепрыгнем с примера с циклом на совсем другой пример, а заодно вывернем функции наизнанку и сделаем continuation-passing style, охренеть упростили! Когда ж вы начнёте честно говорить, что и монады, и continuation-ы появляются не от хорошей жизни, на них переходят потом, когда код получается раздутым и с повторяющимися кусками. А тут все танцы были для того, чтобы показать, что функция - это монада, спасибо, это очень важно. Наконец, автор начинает раскручивать стек своих объяснений: оказывается, хвосторекурсивную функцию можно переписать в таком виде, что она останется хвосторекурсивной, просто вместо возврата там будет exit. Хвосторекурсивность не победили.
Зачем в Scala трамплины и как их использовать