Re: Tentative [PATCH]: valclone

[Gordon Henriksen]

Shouldn't Perl make this determination at compile time based upon the 
subroutine's signature? Doesn't seem to me that it is in any way a 
decision for the assembler.

On Tuesday, July 1, 2003, at 04:00 , K Stol wrote:

This is taken from this week's summary, but I thought this post would 
fit
best in this thread.
  Tentative valclone patch
    Luke Palmer has been thinking about value and reference objects. He
    wondered if there was any value in a "valclone" operator alongside
"set"
    and "clone" which would allow the target PMC to decide whether to 
use
    "set" or "clone" semantics. He also offered a patch implementing 
the
    operator if people thought it would be useful. Leo Tötsch wasn't 
sure
    the new operator was necessary.

    Klaas-jan Stol noted that he'd encountered problems with
reference/value
    confusion when he'd been working on his Lua compiler, but he 
wondered
if
    the problem couldn't be solved by having a general, language
independent
    "argument" PMC class. (I'm not sure I understood what he meant by 
this
    so I'm hoping for an explanation with code fragments).

--
Piers
Piers,

I heard your call :-) Here goes...

Maybe it isn't possible what I'd like, but here's what I was thinking 
of.

I don't know Perl that well, and to keep things readable for everybody,
let's suppose we have the following routine in some (non-existent) 
language:

subroutine foo(x, y)
{
    // do stuff
}
.sub _foo
.param Argument x
.param Argument y
# do stuff
ret
.end
Now, when foo is called with arguments which are references to things
("objects"), then only the reference must be copied into the argument
variables.
However, when the arguments are more 'basic' types like integers or
whatever, some languages may require that these are passed by value! 
When
these 'basic' types are implemented as PMCs (which is likely in dyn. 
typed
languages), then the PMC REFERENCE is copied, because that's the 
default for
PMCs.

to clearify:

P0 = new PerlInt
P1 = new PerlInt
P0 = 123
P1 = P0    # now P1 is referencing the PerlInt in P0; changing the 
object
from P1 will affect the PMC referenced                  #  by P0.
inc P1
print P0    # will print "124" !

In Perl, this is the default behaviour (for what I understood): 
everything
is passed by reference. However there are languages (well, there MAY 
be) in
which the 'basic' types are passed by value.
In these cases, we'd need a _clone_ instruction. This would result in:

.sub _foo
.local PerlUndef x
.local PerlUndef y
# now using pseude code, for ease of reading:

#Parameter x:
if actual type of x is a 'basic' type, then
x = clone P5    # P5 is first argument, see PDD for calling conv.
else
x = P5
#Parameter y:
if actual type of y is a 'basic' type, then
y = clone P6 # don't copy reference, but copy whole of object
else
y = P6    # y will reference same object as P6
#do stuff
ret
.end
Obviously, this is not very clean, not to mention fast. So it would be 
nice
to stuff this run-time check into some PMC.
At this very moment I realize that it's not really a matter of some PMC 
type
for arguments, but that it's a matter of adding a operation for PMCs:
something like a "pass_as_argument" operation: the PMC knows what to do:
clone or copy. (now raises the question: is this worth it?)

I know Perl don't has this problem, but there may be languages that do 
have
this problem (and I can mention at least 1 :-). It would be kinda nice 
if
Parrot can easily handle this as well, but that's not up to me to 
decide of
course.

Klaas-Jan


—

Gordon Henriksen
[EMAIL PROTECTED]