Функциональное програмирование , Что за зверь такой

[applegame]

Цитата D_KEY @ 15.03.17, 17:56

Само по себе нет

Ну а тебе какие примеры нужны? Ленивые списки позволяют оптимизировать обработку легко и непринужденно. Без ленивости тоже самое получается либо не так удобно и/или неоптимально. Выбор за программистом.

Цитата Исмаил Прокопенко @ 15.03.17, 18:30

Все что Вы описали мне кажется называется не "ленивые вычисления", а "оптимизация", когда часть компилятора, называемая "оптимизатор" анализируя зависимости выбрасывает неиспользуемый код.

Нет. Оптимизация делается на стадии компиляции, а в данном примере значение переменной flag - на стадии компиляции неизвестно, поэтому компилятор не выбросит функцию heavyFun().

Цитата Oleg2004 @ 15.03.17, 20:59

Вот здесь
Очень хорошее описание - что можно назвать так называемыми "ленивыми вычислениями."
Исчерпывающе

Там много Хаскеля, не думаю, что автор темы осилит.

Сообщение отредактировано: applegame - 15.03.17, 21:29

[Исмаил Прокопенко]

Цитата Oleg2004 @ 15.03.17, 20:59

Вот здесь
Очень хорошее описание - что можно назвать так называемыми "ленивыми вычислениями."
Исчерпывающе

"Самый очевидный плюс ленивых вычислений — если что-то не требуется, оно не будет вычислено."

Не вижу никакого плюса.
Как правило, если у программиста все нормально с головой, он и так не пишет код, который не требуется выполнять.

К тому же все равно не ясно, чем "ленивые вычисления" отличаются от банальной "оптимизации" - стандартной фичи ВСЕХ компиляторов ВСЕХ языков?

Добавлено 16.03.17, 04:20

Цитата applegame @ 15.03.17, 21:28

Оптимизация делается на стадии компиляции, а в данном примере значение переменной flag - на стадии компиляции неизвестно, поэтому компилятор не выбросит функцию heavyFun().

Дык еще со времени СИ (это 50 лет назад) логические операторы вычисляются не до конца если результат уже известен.

Добавлено 16.03.17, 04:28
Вообщем хрень какая-то эта Ваша заливная рыба эти ваши "ленивые вычисления".
Если бы реально была штука полезная - её бы во все языки ввели, как это было с ОО парадигмой, когда из-за ООП истерии ООП стали пихать во все языки

[OpenGL]

Ну вот ещё пример. Была функция

QList<BlaBla> get_all_items()

Оказалось, что её типичное использование -

for(auto item: foo->get_all_items()) {...}

Поэтому она была переписана так, чтобы она возвращала нечто, по чему можно пройтись таким вот for-ом, и у этого нечто была функция to_list, чтобы получить список, если нужен именно он. В языке с ленивостью весь этот огород бы не потребовался - я бы просто объявил список ленивым, и получил бы ровно тот же эффект.

Цитата Исмаил Прокопенко @ 16.03.17, 04:18

К тому же все равно не ясно, чем "ленивые вычисления" отличаются от банальной "оптимизации" - стандартной фичи ВСЕХ компиляторов ВСЕХ языков?

Компилятор, способный на описанную выше оптимизацию, в студию.

[Исмаил Прокопенко]

И потом, все хорошо в теории и красиво смотрится на искусственно подобранных для иллюстрации примерах.

А если опуститься на уровень реализации?

Как я думаю (рассуждая сам с собой), компилятор "ленивых языков" во все точки, где используется значение некоторой переменной А, вставляет на саму переменную А, а ссылку на код, где она вычисляется.

Т.е. компилятор как бы оформляет автоматом все выражения вида А=Б+Г в виде функции int А(int Б, int Г); а потом во все точки, где используется переменная А, вставляет не значение А, а вызов функции А.

Что-то мне не нравится такое решение. Кривое какое-то

Добавлено 16.03.17, 04:38

Цитата OpenGL @ 16.03.17, 04:30

Компилятор, способный на описанную выше оптимизацию, в студию.

Мне не знакомы эти контсрукции.
Приведите пример на СИ или Паскале

Добавлено 16.03.17, 04:41

Цитата OpenGL @ 16.03.17, 04:30

Поэтому она была переписана так, чтобы она возвращала нечто, по чему можно пройтись таким вот for-ом

Хотите сказать, что компилятор хаскеля может распотрошить функцию и вытащить из неё только то, что реально нужно для данного кода?

Т.е. фактически ПЕРЕПИСАТЬ функцию так, чтобы она работала наиболее оптимально?

Тогда это реально круто

[applegame]

Цитата Исмаил Прокопенко @ 16.03.17, 04:18

Дык еще со времени СИ (это 50 лет назад) логические операторы вычисляются не до конца если результат уже известен

Дык в неленивом языке значение функции heavyFun будет вычислено до проверки flag.

Сообщение отредактировано: applegame - 16.03.17, 04:51

[D_KEY]

Цитата Oleg2004 @ 15.03.17, 20:59

Вот здесь
Очень хорошее описание - что можно назвать так называемыми "ленивыми вычислениями."
Исчерпывающе

Описание мне лично не нужно Мне бы реальных кейсов и реального профита.

Добавлено 16.03.17, 09:21

Цитата applegame @ 15.03.17, 21:28

Ну а тебе какие примеры нужны?

Реальные. Синтетику я много где видел и про нее читал.
На практике слышал о проблемах с нежелательным каскадным росте реальных вычислений (когда система долго что-то "считала", а на самом деле "копила" необходимые вычисления и при попытке что-то реально посчитать вылетала по памяти). Слышал, что отлаживать это дело - то еще удовольствие.
Вот хотелось бы услышать хорошие примеры.

Добавлено 16.03.17, 09:44

Цитата applegame @ 15.03.17, 21:28

Оптимизация делается на стадии компиляции, а в данном примере значение переменной flag - на стадии компиляции неизвестно, поэтому компилятор не выбросит функцию heavyFun().

Ну принимай вместо lazy string функцию Нужна мемоизация? Сделай, вроде не сложно

Добавлено 16.03.17, 09:50

Цитата OpenGL @ 16.03.17, 04:30

Была функция

QList<BlaBla> get_all_items()

Оказалось, что её типичное использование -

for(auto item: foo->get_all_items()) {...}

Поэтому она была переписана так, чтобы она возвращала нечто, по чему можно пройтись таким вот for-ом, и у этого нечто была функция to_list, чтобы получить список, если нужен именно он.

Это не ленивость. Это просто range/iterator.

Цитата

В языке с ленивостью весь этот огород бы не потребовался - я бы просто объявил список ленивым, и получил бы ровно тот же эффект.

QList под капотом вроде массив, а не связанный список.
Не надо забывать про ограничения ленивых структур. Односвязный список - ок, но что будем делать в более сложном случае? А вместо односвязных ленивых списков вполне используют классические итераторы/стримы/etc.
Или я тебя не понял? Можешь псевдокодом показать?

[OpenGL]

Цитата D_KEY @ 16.03.17, 09:17

Это не ленивость. Это просто range/iterator.

В данном контексте это вполне можно назвать ленивым вычислением списка.

Цитата D_KEY @ 16.03.17, 09:17

QList под капотом вроде массив, а не связанный список.

Спасибо, но я в курсе

[D_KEY]

Цитата OpenGL @ 16.03.17, 09:56

Цитата D_KEY @ 16.03.17, 09:17

QList под капотом вроде массив, а не связанный список.

Спасибо, но я в курсе

Тогда покажи ленивый массив.

Добавлено 16.03.17, 10:06

Цитата OpenGL @ 16.03.17, 09:56

Цитата D_KEY @ 16.03.17, 09:17

Это не ленивость. Это просто range/iterator.

В данном контексте это вполне можно назвать ленивым вычислением списка.

Ну давай еще так назовем стандартные плюсовые итераторы ввода, например
Тут же нет никакого создания списка. Ленивый список создается по мере надобности. У тебя же список создаётся только если функцию вызвать, причем создается он, опять же, целиком. Нет?

[OpenGL]

Я не понимаю, что ты от меня хочешь. Я показал пример, когда бы ленивость была удобнее, и описал, что пришлось сделать из-за ее отсутствия. Причём тут массивы и создание списка целиком при вызове метода?

[Flex Ferrum]

D_KEY, в плане примеров использования ленивых список (в частности) и ленивых вычислений вообще - могу привести свой кейс. У меня есть проект, в основе которого лежат различные операции на гиперграфе - выборка узлов, фильтрация, трансформация, сложные предикаты и прочие прелести. Понятно, что есть группа операций, в которых надо, например, обойти все связанные узлы, соответствующие некоторому критерию. А есть группа операций поиска, в которых итерации надо прерывать в момент нахождения узла. Для всего этого я и использую ленивые списки, которые ещё и в цепочки могу выстраивать с традиционными операциями map/filter/zip и т. п.

[D_KEY]

Цитата OpenGL @ 16.03.17, 10:21

Я не понимаю, что ты от меня хочешь. Я показал пример, когда бы ленивость была удобнее, и описал, что пришлось сделать из-за ее отсутствия.

Ты не показал, чтобы ты сделал, если бы ленивость была
Так же не объяснил, почему не сделал/не использовал реализацию ленивых структур данных для плюсов.

Добавлено 16.03.17, 11:04

Цитата Flex Ferrum @ 16.03.17, 10:30

D_KEY, в плане примеров использования ленивых список (в частности) и ленивых вычислений вообще - могу привести свой кейс. У меня есть проект, в основе которого лежат различные операции на гиперграфе - выборка узлов, фильтрация, трансформация, сложные предикаты и прочие прелести. Понятно, что есть группа операций, в которых надо, например, обойти все связанные узлы, соответствующие некоторому критерию. А есть группа операций поиска, в которых итерации надо прерывать в момент нахождения узла. Для всего этого я и использую ленивые списки, которые ещё и в цепочки могу выстраивать с традиционными операциями map/filter/zip и т. п.

Спасибо. Вроде да, хороший пример. Хотя если просто обойти, то разве не достаточно некоего range/iterator? Или нужно/полезно хранить предыдущие объекты, обходить несколько раз или иметь несколько ссылок на список?

[Flex Ferrum]

Цитата D_KEY @ 16.03.17, 11:00

Спасибо. Вроде да, хороший пример. Хотя если просто обойти, то разве не достаточно некоего range/iterator? Или нужно/полезно хранить предыдущие объекты, обходить несколько раз или иметь несколько ссылок на список?

Там фишка в том, что могут цепочки набираться в стиле:

auto GetPropertyNodes(EntityPtr entity)
{
   return entity->GetOutgoingRelations().filter([](RelationPtr rel) {return rel->GetKind() == property;}).map([](RelationPtr rel) {return rel->GetSecondEntity();}
}
 
//...
auto proertyNames = GetPropertyNodes(entity).map([](EntityPtr& entity) {return entity->GetName();});
 
bool hasUnnamed = std::find(propertyNames.begin(), propertyNames.end(), [](const std::string& name) {return name.empty();}) != propertyNames.end();

Добавлено 16.03.17, 11:13
В итоге, тебе известен только первый диапазон, по которому делается фильтрация. А потом один маппинг, другой, меняется тип результата, ну и т. п.

Сообщение отредактировано: Flex Ferrum - 16.03.17, 11:13

[OpenGL]

Цитата D_KEY @ 16.03.17, 11:00

Ты не показал, чтобы ты сделал, если бы ленивость была

Написал бы lazy.

Цитата D_KEY @ 16.03.17, 11:00

Так же не объяснил, почему не сделал/не использовал реализацию ленивых структур данных для плюсов.

Потому, что у меня нет привычки решать простые задачи сложными способами

[D_KEY]

Цитата OpenGL @ 16.03.17, 12:06

Цитата D_KEY @ 16.03.17, 11:00

Ты не показал, чтобы ты сделал, если бы ленивость была

Написал бы lazy.

Куда?

Цитата

Цитата D_KEY @ 16.03.17, 11:00

Так же не объяснил, почему не сделал/не использовал реализацию ленивых структур данных для плюсов.

Потому, что у меня нет привычки решать простые задачи сложными способами

А как же

Цитата

Поэтому она была переписана так, чтобы она возвращала нечто, по чему можно пройтись таким вот for-ом

Добавлено 16.03.17, 12:53

Цитата Flex Ferrum @ 16.03.17, 11:11

В итоге, тебе известен только первый диапазон, по которому делается фильтрация. А потом один маппинг, другой, меняется тип результата, ну и т. п.

Так range это позволяют. Если тебе не нужны, условно, предыдущие элементы и результаты, то зачем их держать? Перешел в результате обхода к следующему элементу и все.
Другое дело, если эти элементы нужны, будут использоваться повторно, на них имеются несколько ссылок и т.д.

[OpenGL]

Цитата D_KEY @ 16.03.17, 12:45

Куда?

На стену.

Цитата D_KEY @ 16.03.17, 12:45

А как же

Ты слишком толсто и явно троллишь. Давай тоньше