# Re: Polymorphism and Representations

```HaloO,

John M. Dlugosz wrote:
```
You want a way to declare the function to accept both lvalue and non-lvalue items, and determine at run-time whether it can write back to it.

```
Yes, but as a general feature. Any assignment checks the constraint
of the lvalue. A non-writeable lvalue is simply having an impossible
constraint. That amounts to "everything does lvalue upto a constraint".
So effectively everything becomes an lvalue.

```
The MMD matching solution does not require return type matching. The information "does this conform" is part of the parameter types.
```
multi sub foo (Num \$x is ro) { ... }
multi sub foo (Num \$x is rw) { ... }

```
The second is not a candidate if you pass a literal, a constant, whatever.
```
OK, this is the easy case insofar as the Num in the signature
does syntactic double duty in first constraining the type of the
input towards *more* specific types and then constraining the container
towards *less* specific types.

```
The second is considered a better match when it is a candidate by virtue of the ordering rules.
```
Where do you get the information from that the second is more
specific than the former? Consider

constant Num \$c = 3; # Num here is funny
my       Num \$n = 3;
my       Int \$i = 3;
my       Any \$a = 3;

And now \$i is more specific than \$n? Would a call to foo with \$i
dispatch to the ro case? Is \$a more specific than \$n? Note that undef
is the only "value" that meets the impossible constraint. So calling
the rw foo with \$i might store an undef. Not to mention the autocoercion
of Num to Int upon assignment. Do you expect the dispatch take that into
account as well? Consider

multi foo (Int \$x) {...}

Is this more specific than the second when called with \$n? How
do 'is ref' and 'is copy' fit in your sort order? My reading is
that the parameter traits are *not* dispatch relevant. Therefore
your two multis are an error because of indistinguishable signature.

Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan
```