Oℕ
Ещё одна (или не одна) особенность, дающая потенциал для оптимизаций в ФП, должна быть включена в язык, но пока не включена в scala, хотя и обсуждалась
Size: a a a
2020 August 23
OO
а что-то ж было про представление гарантированно-чистых функций, емнип через синтаксис -> вместо =>
OO
но это года 3-4 назад было, так что заглохло, видимо
EB
scala только только собирается получить первый компилятор с промежуточным представлением перед JVM bytecode, все нетривиальные оптимизации требуют такого представления.
Некоторые даже должны были быть включены в релиз, но пока отложены.
Я тоже полагаю, что есть у ФП кода есть потенциал производить более эффективно работающие приложения, но это вопрос следующего этапа и вовлечённости сообщества в компилятор.
Некоторые даже должны были быть включены в релиз, но пока отложены.
Я тоже полагаю, что есть у ФП кода есть потенциал производить более эффективно работающие приложения, но это вопрос следующего этапа и вовлечённости сообщества в компилятор.
Я помню, в этом чате обсуждалось, что в скала в рамках одного метода мутируемая структура это норм, главное чтобы результат функции был иммутабельный. А у вас в продакшн коде есть методы которые внутри себя реализуют алгоритмы с мутабельными структурами? или у вас все очень строго?
NV
Я помню, в этом чате обсуждалось, что в скала в рамках одного метода мутируемая структура это норм, главное чтобы результат функции был иммутабельный. А у вас в продакшн коде есть методы которые внутри себя реализуют алгоритмы с мутабельными структурами? или у вас все очень строго?
Стандартная либа коллекций наполовину такая
OO
Я помню, в этом чате обсуждалось, что в скала в рамках одного метода мутируемая структура это норм, главное чтобы результат функции был иммутабельный. А у вас в продакшн коде есть методы которые внутри себя реализуют алгоритмы с мутабельными структурами? или у вас все очень строго?
не столько "результат иммутабельный" (это иррелевантно целям), сколько "созданные внутри метода мутабельные вещи никак не экспозятся наружу"
NV
не столько "результат иммутабельный" (это иррелевантно целям), сколько "созданные внутри метода мутабельные вещи никак не экспозятся наружу"
А какая разница?
Oℕ
а что-то ж было про представление гарантированно-чистых функций, емнип через синтаксис -> вместо =>
да
OO
А какая разница?
вопрос терминологии
может, там в методе сайдэффектом изменяется публично доступная переменная класса, но именно результат метода все еще остается иммутабельным
например, счетчик числа вызовов этого метода
может, там в методе сайдэффектом изменяется публично доступная переменная класса, но именно результат метода все еще остается иммутабельным
например, счетчик числа вызовов этого метода
EB
но на определение чистоты функции же не влияет, использует она внутри мутабельные структуры или нет?
OO
не влияет
Oℕ
На определение кем?
EB
скала чатом
Oℕ
Уверен, что скалачат не сможет прийти к консенсусу относительно ни одного даже самого простого определения
Oℕ
не столько "результат иммутабельный" (это иррелевантно целям), сколько "созданные внутри метода мутабельные вещи никак не экспозятся наружу"
Ну вот например cats.Eval[Int] может быть результатом иммутабельной функции согласно этому определению?
OO
Ну вот например cats.Eval[Int] может быть результатом иммутабельной функции согласно этому определению?
может, если внутри нет сайдэффектов
OO
(и я не очень понял, что такое "иммутабельная функция")
AD
(и я не очень понял, что такое "иммутабельная функция")
Код который не меняется с выполнением инструкций?
OO
Код который не меняется с выполнением инструкций?
принимается
AH
Код который не меняется с выполнением инструкций?
konst комбинатор)