Inversion-of-control resource management

[shelby3]

@keean

Note I can reuse the buffers, swapping x for y, so a chain of maps of any length can be done using only two buffers.

map(x.first(), x.len(), y.first_mut(), |a| a + 1);

Our proposals appear to have equivalent composability.

Mine inverts the roles of the function arguments and functions inside out:

y.first_mut(|f1| y.len(|n| x.first(|f0| map(f0, n, f1, |a| a + 1))));

The nesting order doesn't matter:

y.first(|f0| y.len(|n| x.first_mut(|f1| map(f0, n, f1, |a| a + 1))));

I wish the compiler allowed to write that as:

y.first(y.len(x.first_mut(map($1, $2, $3, $4 + 1))));

The above is missing the alternative invocation within each anonymous ("closure") function employing a single input argument when restarting from yield.

Thus I need some macro to make invoking mine as intelligible as yours, such as perhaps:

map(x.first(_), x.len(_), y.first_mut(_), |a| a + 1);

Note the reason for the (_) above is because these functions may also take other input arguments.

@keean

Although map is actually a special case and can be implemented over a single mutable buffer.

You didn't address the case of needing two or more mutable iterators on the same collection. For example bubble sort.

Edit: The reason is because for each mutable iterator you need a mutable reference to the collection. Whereas, with my proposal, there is only one mutable reference to the collection which is borrowed for each nesting of the call chain. However, that borrowed nesting is not explicit in the signature I wrote upthread. I will need to think about how to make it explicit to the compiler. The salient point is mine is a functional nesting, so borrowing can be applied.

@keean

@shelby3

Also your proposal is very imperative and doesn't encapsulate the lifetimes orthogonal to the part of the algorithm which decides when to call successor. Whereas, my proposal keeps all the algorithm logic including that successor timing logic all in the same callback function. Afaics, the distinction is monumental.

This is vital, as otherwise you cannot implement many algorithms. Look at the algorithms from EoP and you will see when and how many times successor is called is a critical part of every algorithm. Otherwise you are trying to reduce every algorithm to a 'foreach' over a closure with mutable state.

Ostensibly you have not read point #5 carefully in my reply to @nielsle. My proposal can do everything yours can and without losing that separation-of-concerns.

My proposal is employing yield to tell the caller when to call successor and supply a new value. And my proposal can signal each iterator separately by changing the value that is yielded. It is not limited to successor and any state change on each iterator can be signaled to the nested recursion of callers.