Ребят ФП-ки, теоретический вопрос: изучая Haskell стало понятно что чистые функции и выражения дают большие возможности для различных оптимизаций на уровне компилятора, в частности ленивость (здесь есть шаринг выражений и различные стадии вычислений). Есть ли что-то подобное на уровне компилятора Скалы ?

нет

компилятор скалы "не знает", есть ли у вашего кода побочные эффекты, он не умеет

это на всяких интересных оптимизациях ставит крест

Подскажите пожалуйста кто со сликом знаком, безопасно ли делать вот так вот:

filter(_.name.like(s"%$sq%"))

Где sq - произвольная строка получаемая от юзера? т.е. слик это заескейпит, или у меня тут будет sql injection?

В Haskell есть спец тип IO для этого, странно , что в Скала 3 в этом плане ничего не сделано для сообщества, которое активно развивает ФП в Скале.

аналогичный тип есть и в скале, но нет гарантий на уровне компилятора, что юзер не напишет сайдэффект в выражении с таким типом

filter(_.name.like(s"%$sq%"))

Заэскейпит

Спасибо

Олег, а что ты имел в виду, когда говорил, что Скала 3 будет более функционалой, больше сахара?

ФП сообщество в scala последние 5 лет неизменно укрепляется. Настолько укрепилось, что сегодня это  мейнстрим и практически все новые либы фпшные.
И большая часть проблем в scala 2, которые решали в scala 3 были сформулированы ими и решали их потребности.
Новый массивный редизайн имплиситов в виде полу-тайпклассов, автоматически расширяющих синтаксис и дающих возможность вывода.
Все замуты на типах, такие как матч типы, опак типы, кайнд полиморфизм - все решают потребности ФП.
Несколько новых видов функций и унификация старых. Компактный синтаксис для (Г)АДТ.
Все остальные фичи полезны для ФП и для ООП одновременно, вроде хайлевел определений, трейт параметров и т.п
Единственная фича, которая для ООП возможно более полезна, чем для ФП - это экспорт.

Проблема в том чтобы выяснить чистоту функции нужно выяснить чистоту джавакода и скалакода, так что это весьма сложно.

Нет, никаких особенных оптимизаций в скале нет. Более того, ФП-код медленнее императивного. Так что основное преимущество ФП в скале - это простота кода.

Это скорее вопрос к разработчикам компиляторов, почему ФП код медленнее. Довольно странно, что в 21 веке декоративное программирование до сих пор не победило и мы вынуждены работать с низкоуровневыми концептами вроде переменная и процедура. Насчёт простоты ФП кода я бы поспорил, тк это совсем другой стиль программирования и голову нужно перестраивать. Основной плюс ФП что он удобен при конкурентном программировании и соответственно навязывается разрабами библиотек. Хотелось бы в будущем иметь поддержку ФП на уровне инфраструктуры (компиляторы, GC)

Декоративное?

Сори, декларативное

+ мне нравится такое название

А есть замеры? Очень интересно посмотреть.

scala только только собирается получить первый компилятор с промежуточным представлением перед JVM bytecode, все нетривиальные оптимизации требуют такого представления.
Некоторые даже должны были быть включены в релиз, но пока отложены.
Я тоже полагаю, что есть у ФП кода есть потенциал производить более эффективно работающие приложения, но это вопрос следующего этапа и вовлечённости сообщества в компилятор.