Dan --
> *) There's going to be a bunch of named argument stuff that we should
> (though don't have to) put support in for. Perl 6 is going to make
> heavy use of them.
I may be terminologically challenged here (if so, please forgive), but
this sounds like passing a single pad as *the* argument, so the pad
gets inserted into the lookup chain. Various optimizations seem
possible:
* Caller knows canonical order, and pad has a way to designate
both name and offset. Caller specifies by index, and callee can get
at them by their indexes rather than names.
* Caller doesn't know canonical order, so slaps names and values
into a pad and hands it off to callee. Callee probably does
an ordering of things so the indexes are where they need to be
and uses indexed pad access from there on out.
Speed makes us want the insides of the subs to be implemented as
by-register (or at least by-index) even when the call is constructed
by-name.
Of course, there are some by-name semantics that don't fit this model.
You have the exists/defined ambiguity for missing args if you do
anything other than pass a hash or equivalent. So, I think some subs
might want to specify that they do get their args this way so they
can test whether an arg was specified or not (its essentially this:
by-hash would allow you to detect omitted by-name args, and by-pad
would just have them undef or otherwise defaulted [???]).
But, it makes me wonder if we should have metadata on call-points
and have the interpreter do the tinkering in the middle. This way,
a sub could be compiled into an named-pad-access, indexed-pad-access
or register-access form, and annotated as such. The caller can
construct its call in whichever way is convenient and the interpreter
maps on call.
# By name call pseudo-imc
.call foo
.arg{bar} 1
.arg{splee} $S3
.go
# By index call pseudo-imc
.call foo
.arg[0] 1
.arg[1] $S3
.go
I guess the interpreter would assume basic by-reg calling unless it
was able to access metadata for the sub. If it does find metadata
and there are names for the args, then it is possible to do by-name
calling.
I'm not clear, though, on what the Parrot representation of
sub quux {
print "baz= ", shift, "\n";
print "ni= ", shift, "\n";
}
would be. It smells like another arg convention: by-array (meaning
all args get slurped into a single array passed to the sub), or
possibly by-pad (with the @_ entry pointing to the args).
IMO, it should be possible for compiler writers to spit out their
calls and defs as IMC in terms natural to what they are doing, and
imcc and the interpreter should conspire to make things as fast as
possible and complain when things aren't compatible.
If we have metadata with names, Parrot types and canonical order
of the args, then any of the caller styles can be mapped to any
of the callee styles.
Regards,
-- Gregor
