Здравствуйте, AlexRK, Вы писали:

ARK>Понял. То есть речь просто о сахаре для вызовов цепочек функций.

Ну там не только для организации цепочки, но и ещё нескольких близких нюансов.

ARK>Тогда зачем же притягивать целый ФЯ?

Ну так в этих ФЯ это есть из коробоки, а скажем в C++ нет. ))) Другое дело, что скажем взяв соответствующую библиотеку (например такую https://github.com/beark/ftl) мы легко получим подобное и в C++... Но сторонники всяческих маргинальных языков обычно игнорируют этот аргумент. )))

Здравствуйте, Ikemefula, Вы писали:

I>А как ты думаешь это всё работает унутре ? Этот 'просто сахар' внятной поддержки компилятора, рантайма и фремворка. В частности, нужны толковые структуры данных. Кроме того обязательно требуются замыкания. Замыкания для полноценной реализации требуют GC. Опаньки !

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

Здравствуйте, AlexRK, Вы писали:

ARK>А без аналогий можете пояснить, что в моем случае не так?

Отсутствует абстракция. Тело твоего "комбинатора" комбинирует заведомо известные ф-ии. Надо, чтобы он умел комбинировать ф-ии, поданные как аргументы.

Здравствуйте, Ikemefula, Вы писали:

I>GC и замыкания это 90% от ФЯ Замыкания нужны для комбинирования функций.

Для комбинирования не нужны ни разу.

Здравствуйте, Ikemefula, Вы писали:

V>>Так и есть. Для одного из самых убогих языков — Джавы, серьезная инфраструктура появилась одной из первых.
I>"одной из первых" — смеялся. Эдак окажется, что до джавы жизни вообще не было.

Настолько всеобъемлющая инфраструктура была только для COM/DCOM/COM+/ActiveX/OLE. Но степень удобства для разработки была намного ниже, разве что на VB/VBA неплохо получалось в плане удобства. Но на этом языке невозможно было выразить и/или использовать все возможности низлежащей платформы.

Та же CORBA отставала и оч сильно. Ну и всё, собсно. Среды для Smalltalk, Forth, ObjectPascal были намного попроще и намного `уже по покрытию прикладных областей "изкаробки".

Здравствуйте, vdimas, Вы писали:

I>>GC и замыкания это 90% от ФЯ Замыкания нужны для комбинирования функций.

V>Для комбинирования не нужны ни разу.

Ога.

Здравствуйте, alex_public, Вы писали:

I>>А как ты думаешь это всё работает унутре ? Этот 'просто сахар' внятной поддержки компилятора, рантайма и фремворка. В частности, нужны толковые структуры данных. Кроме того обязательно требуются замыкания. Замыкания для полноценной реализации требуют GC. Опаньки !

_>Вот не надо повторять везде этот миф, что типа для замыканий обязательно нужен сборщик мусора.

Не надо называть костыли в С++ замыканиями и все будет хорошо.

Здравствуйте, Ikemefula, Вы писали:

I>Не надо называть костыли в С++ замыканиями и все будет хорошо.

При чём тут С++? Для иммутабельных замыканий GC не нужен ни разу, т.к. сразу отсутствует требование передачи контекста по ссылке.

Здравствуйте, vdimas, Вы писали:

I>>Не надо называть костыли в С++ замыканиями и все будет хорошо.

V>При чём тут С++? Для иммутабельных замыканий GC не нужен ни разу, т.к. сразу отсутствует требование передачи контекста по ссылке.

GC нужен для upward funarg

Здравствуйте, Ikemefula, Вы писали:

V>>При чём тут С++? Для иммутабельных замыканий GC не нужен ни разу, т.к. сразу отсутствует требование передачи контекста по ссылке.
I>GC нужен для upward funarg

Еще раз по-русски.
Это только для мутабельных сценариев.

Здравствуйте, vdimas, Вы писали:

V>>>При чём тут С++? Для иммутабельных замыканий GC не нужен ни разу, т.к. сразу отсутствует требование передачи контекста по ссылке.
I>>GC нужен для upward funarg

V>Еще раз по-русски.
V>Это только для мутабельных сценариев.

Покажи кодом.

Здравствуйте, Ikemefula, Вы писали:

I>Не надо называть костыли в С++ замыканиями и все будет хорошо.

А какие к ним претензии? )

Здравствуйте, Ikemefula, Вы писали:

I>GC нужен для upward funarg

Ерунда это. Можно обсуждать только вопросы эффективности (по быстродействию) решения, а само оно есть в любом языке с возможностью написания функторов (в терминологии C++).

Для решения же проблемы быстродействия (т.е. грубо говоря копирования больших кусков данных) возможны различные решения, типа дополнительных лёгковесных контейнеров, автоматического подсчёта ссылок и т.п. Но скажем в C++ с появлением move semantics в последней версии стандарта про проблему быстродействия можно смело забывать... )))

Здравствуйте, alex_public, Вы писали:

I>>GC нужен для upward funarg

_>Ерунда это. Можно обсуждать только вопросы эффективности (по быстродействию) решения, а само оно есть в любом языке с возможностью написания функторов (в терминологии C++).

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

_>Для решения же проблемы быстродействия (т.е. грубо говоря копирования больших кусков данных) возможны различные решения, типа дополнительных лёгковесных контейнеров, автоматического подсчёта ссылок и т.п. Но скажем в C++ с появлением move semantics в последней версии стандарта про проблему быстродействия можно смело забывать... )))

Так себе решение.

Здравствуйте, Ikemefula, Вы писали:

I>Вот видишь, о чем и речь — ты смотришь исключительно с т.з. быстродействия, но почему то считаешь, что и другие делают тоже самое.

Так если забыть о быстродействие, то как бы и вообще проблем нет — просто все нужные данные тупо копируются в возвращаемый функциональный объект.

Или может ты какие-то ещё проблемы укажешь? )

Здравствуйте, alex_public, Вы писали:
_>Или может ты какие-то ещё проблемы укажешь? )

Покажи, где и как освобождать память.

Здравствуйте, Ikemefula, Вы писали:

V>>>>При чём тут С++? Для иммутабельных замыканий GC не нужен ни разу, т.к. сразу отсутствует требование передачи контекста по ссылке.
I>>>GC нужен для upward funarg

V>>Еще раз по-русски.
V>>Это только для мутабельных сценариев.

I>Покажи кодом.

Что тебе даст код?

#include <boost/assign.hpp>

int main(int argc, char* argv[])
{
    using namespace std;
    using namespace boost::assign;

    vector<int> vec;
    vec += 10, 2, 31, 15, -5, 42;

    int max = 15;

    // по значению
    sort(vec.begin(), vec.end(), [=](int lhs, int rhs) {
        return lhs < rhs && rhs < max;
    });

    // по ссылке
    sort(vec.begin(), vec.end(), [&](int lhs, int rhs) {
        return lhs < rhs && rhs < max;
    });

    return 0;
}

В первом случае замыкание можно безопасно сохранить во внешнем контексте, во втором — нет.

Тебе этот код помог? ))
Для понимания рассуждений надо было сообразить, что в иммутабельном сценарии становится не важно, как передаются данные — по ссылке или по-значению. А код тут только мешает.

Здравствуйте, Ikemefula, Вы писали:

_>>Ерунда это. Можно обсуждать только вопросы эффективности (по быстродействию) решения, а само оно есть в любом языке с возможностью написания функторов (в терминологии C++).
I>Вот видишь, о чем и речь — ты смотришь исключительно с т.з. быстродействия, но почему то считаешь, что и другие делают тоже самое.

Ну да. Поэтому ты пользуешься ГЦ, а другие коллеги не могут себе позволить этой роскоши.


_>>Для решения же проблемы быстродействия (т.е. грубо говоря копирования больших кусков данных) возможны различные решения, типа дополнительных лёгковесных контейнеров, автоматического подсчёта ссылок и т.п. Но скажем в C++ с появлением move semantics в последней версии стандарта про проблему быстродействия можно смело забывать... )))

I>Так себе решение.

Явная передача владения — это не так себе. Это нечто близкое к происходящему при передаче владения в uniqueness-типах.

Здравствуйте, Ikemefula, Вы писали:

I>Покажи, где и как освобождать память.

)))
Покажи, где и как освобождать память для value-type в дотнет?

Здравствуйте, vdimas, Вы писали:

V>>>>>При чём тут С++? Для иммутабельных замыканий GC не нужен ни разу, т.к. сразу отсутствует требование передачи контекста по ссылке.
I>>>>GC нужен для upward funarg

V>Что тебе даст код?

Ты показал downward, а надо было upward