adapters to transform local and remote lambdas

[bwpriest]

We've discussed ideas surrounding lambda manipulation for a while, so we should probably coalesce the continuing conversation in a dedicated thread. We are in the process of instituting compiler guards on our lambda interface, and have settled upon support for [](const key_type&, value_type&, Args...){} lambdas for key-value stores (map, array, counting_set, etc) and [](value_type, Args...){} for value stores (bag, set, etc).

However, we would like to have an interface to manipulate these lambdas. There are two major types of adapters that we have discussed: signature adapters that modify the signature of the lambdas in some way and interface adapters that change the elements to which the lambda is applied.

We currently support both [](const key_type &, value_type &){} and [](value_type &){} local lambdas for key-value stores via template metaprogramming. However, it would be more future-proof to instead pass lambdas through some adapter that drops the key type. It will also be necessary for remote lambdas, as there is presently no way to distinguish between [](ptr_type &, value_type &){} and [](const key_type &, value_type &){} signatures if the lambda uses auto typenames.

We've discussed a few different interface adapters. For example, it would be nice to apply a lambda to a randomized sample of objects (discussed in #131 and prototyped in a non-adapter way in #124). We have also discussed applying filters or masks onto key-value stores so that lambdas are only applied to certain elements, e.g. all values with numeric keys > 0 or all values with string keys matching a regex.

[rogerpearce]

I'm in favor of the for_all_adapter concept. I'm not seeing how and adapter would work for remote lambdas though.

[bwpriest]

I concur that adapters for remote lambdas probably don't make sense. So we want a separate for_all_adapter() function, or do we want to add an optional argument to for_all()?