Программисту не очень интересно, что себе думает GC. С точки зрения процессора вообще нет ни GC, ни переменных, ни функций, — только одно мутабельное пространство памяти.
Мы же рассуждаем о мутабельности с точки зрения программиста и семантики языка.
Да и точки зрения зрения GC «мутабельная ровно 1 раз» переменная от настоящей мутабельной отличается существенно, о чём было высказывание выше.
Второй вариант хороший. STM его обеспечивает. Поскольку чтение и запись регистра — императивный эффект, Хаскель обеспечивает порядок. Очень плохо, что в вашем языке последовательность чтений из записей не определена. Переходите на Хаскель.
Т.н. "вычисление" не может достать что-то из БД или не может вызвать системную функцию?
Не может (без unsafe).
И функции внутри функциональной композиции не могут иметь "действия"?
Действия могут зависеть от параметров, тогда они будут функциями, тогда их можно композить с функциями как обычные функции, но при этом не будут композиться эффекты.
Для композиции эффектов есть другие комбинаторы, похожие но композицию чистых функций.
Да, я имел ввиду именно негарантированный и вообще неявный порядок вычисления, когда вы делаете сложную композицию из функций, которые внутри содержат некие действия с общим стейтом.
Вот это как раз невозможно (возможно только если специально стрелять себе в ногу через unsafe). Неявное изменение порядка вычислений есть, но оно не вредит, а либо не имеет значения, либо помогает.
И я так думаю, это именно те случаи, которые имел ввиду Игорь Шевнин в своей фразе.
Я уверен, что нет. Иногда хочется разобраться в деталях, например, чтобы оптимизировать скорость или расход памяти, и только в этом случае ленивость сложнее императивного кода. Хотя на этот случай есть инструменты управления энергичностью и ST для локального отказа от ленивости в пользу явного управления порядком и присваиваний в обычные изменяемые переменные.
Я не глубокий специалист в лиспе, надеюсь, кто-нибудь поправит. Знаю только, что есть много разных лиспов: изначальный Лисп МакКарти — совсем императивный, в Common Lisp есть элементы ФП, в Scheme их ещё больше.
Преподавали, наверно, потому что в нём есть базовые элементы ФП — лямбда-абстракция и замыкание, а также односвязный список в сердце языка. Но шаг в сторону — и появляются мутации. С комбинаторами не так удобно работать, как в языках с синтаксисом ISWYM (*ML, Haskell). С таким же успехом можно на Питоне и С++ преподавать ФП.
Так что Лиспы считаются функциональными, но примерно в той же степени, что и Питон.
Если между этими строчками прилетит исключение, финализатор никогда не вызовется? С этим можно как-то бороться?
1. www.fpcomplete.com/blog
2. book.realworldhaskell.org
3. talks from any FP conference
Мы же рассуждаем о мутабельности с точки зрения программиста и семантики языка.
Да и точки зрения зрения GC «мутабельная ровно 1 раз» переменная от настоящей мутабельной отличается существенно, о чём было высказывание выше.
20 лет назад хаскельные компиляторы оптимизировали хуже, чем Ява.
Поиск по вики есть — https://github.com/ruHaskell/ruhaskell/search?q=IDE&type=Wikis
Хотя там всего несколько страниц, можно по их списку пройтись.
А ещё можно задавать вопросы в наших чатах — https://ruhaskell.org/links.html
Не может (без unsafe).
Действия могут зависеть от параметров, тогда они будут функциями, тогда их можно композить с функциями как обычные функции, но при этом не будут композиться эффекты.
Для композиции эффектов есть другие комбинаторы, похожие но композицию чистых функций.
Вот это как раз невозможно (возможно только если специально стрелять себе в ногу через unsafe). Неявное изменение порядка вычислений есть, но оно не вредит, а либо не имеет значения, либо помогает.
Я уверен, что нет. Иногда хочется разобраться в деталях, например, чтобы оптимизировать скорость или расход памяти, и только в этом случае ленивость сложнее императивного кода. Хотя на этот случай есть инструменты управления энергичностью и ST для локального отказа от ленивости в пользу явного управления порядком и присваиваний в обычные изменяемые переменные.
Преподавали, наверно, потому что в нём есть базовые элементы ФП — лямбда-абстракция и замыкание, а также односвязный список в сердце языка. Но шаг в сторону — и появляются мутации. С комбинаторами не так удобно работать, как в языках с синтаксисом ISWYM (*ML, Haskell). С таким же успехом можно на Питоне и С++ преподавать ФП.
Так что Лиспы считаются функциональными, но примерно в той же степени, что и Питон.