HaloO, John M. Dlugosz wrote:
But, I'm thinking along the lines of Pascal and C++. You can't pass a non-lvalue "by reference", period. (5)++ is just plain wrong.
Hmm, I would like the error to show up *within* the body of ++. Your idea is to statically derive the error from the 'is rw' trait in the signature.
The matching rules for MMD should be at least as good as C++ overloading, to have a version of the function that is for non-lvalues and one that is for lvalues.
Ohh, conceptually we should split the 'r' and 'w' in 'rw'. The r part is for the value going in. The w part is conceptually part of the *return* type of the function. The convenience for the caller lies in the fact that she doesn't have to extract the values of interest from the returned Capture. The syntactic problem I'm trying to point out is that the return type and parameter type in a rw signature entry share the same slot. Note that return type tie breaking is only conjectured. I doubt its usefulness anyway. E.g. asking a Go Professional where to play next is easy insofar as you could just play the move. But the answer to asking why could easily be beyond your understanding. Now is it advisable to ask a lesser expert for a move and and a rational that matches your constraints? > Also, Perl 6 synopses mentions both 'rw' and 'ref'
separately.
Indeed, that is puzzling me a lot. IIRC, it states that rw is more forgiving when the argument is no lvalue. What else could that be than a relaxed invariance?
I think there will be a choice of copy/return or ref binding for 'rw', which allows for differing types; and bind directly with 'ref' which allows for custom container ties to work live rather than just get an update at the end.
As far as rw is concerned this very much sounds as what I say above, except that the programmer has no way to interfere. That is to play it nice for th caller.
We need a clear summary of expectations; that is, what do we want to be able to accomplish. Then refactor that into a set of real features that span the target feature set.
I think that invariance of rw or ref parameters is a too tight constraint. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
