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

Reply via email to