Change to the calling convention, and other fallout from last week's perl 6 meeting
Dan Sugalski
directly impact parrot, there are a few things that will. I'm pretty
late as it is, so I figured I'd give a quick summary before digging
through the pending p6i mail and dealing with these in depth. In
order:
*) We need to get Leo's concerns about string reusability dealt with.
(Which, strictly speaking, wasn't discussed but it's been hanging too
long) We're generating too many new strings. Fooey.
*) The vtable split needs to be defined and implemented. I'd like
some macros to access the vtable entries themselves, since there may
be a number of structural changes and I don't want to have to keep
redoing the code every time some element shifts from one spot to
another.
*) I'd like to get access to pmc elements done via macros as well--I
think it's time to split PMCs into pieces, since we're definitely
trashing the cache in the common case with things we don't commonly
need. (Like the metadata, thread, and GC stuff) PMCs are 40 bytes on
my PPC system. Too much cache fluff.
*) We're going to have to maintain properties on both PMCs and the
values in PMCs. I'm not sure yet how to do this without adding a
second property pointer, which we may end up doing. I'm not sure yet
*) multimethod dispatch became much less important, which is both
good and bad. I'll get to that later
*) We (that is, us) get to define the event, thread, and IO systems,
which we should do at some point if I want to avoid being the target
of a pie. (Though I'm quite willing to be one if it'll encourage
folks. Including me :)
*) 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.
*) One change to the calling convention--optionally passing in the
name of the sub/method you're invoking. This is for autoloadish
things where we may be making a call to foo, but really got
GENERIC_FALLBACK_METHOD or something.
I think that's the big things. I'll start digging through the list
now to see what was up while I was gone. (So prepare for old and
stale answers :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
gre...@focusresearch.com
> *) 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
Dan Sugalski
>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.
We could do that, but I'm not sure it's worth it. Here's a quick
explanation of what I mean by named args.
With perl 6, you'll be able to have signatures like:
method foo($bar, $baz, @quux; $other) {}
which you can call either positionally or by name. A positional call would be:
object.foo(1, 2, @array)
and a named call would be:
object.foo(other => "Fred", quux => @array, bar => 1, baz => 2)
where the names of the parameters in the signature map to names on
the LHS of the arrow. (Keeping in mind that the "foo => 1" construct
builds a single pair object, rather than two scalars, and that arrays
and hashes get passed as a single thing unless explicitly flattened)
There are some rules for mixing positional and named parameters,
which I need to dig out.
The end result is that it's the callee's responsibility to make the
name->parameter mapping, not the caller, since you can't guarantee
that you're not going to get intercepted and redirected to a method
with a different signature, or with the same parameters in a
different order.
Leopold Toetsch
>
> *) The vtable split needs to be defined and implemented. I'd like some
> macros to access the vtable entries themselves, since there may be a
> number of structural changes and I don't want to have to keep redoing
> the code every time some element shifts from one spot to another.
http://archive.develooper.com/perl6-i...@perl.org/msg14250.html
> *) I'd like to get access to pmc elements done via macros as well--I
> think it's time to split PMCs into pieces, since we're definitely
> trashing the cache in the common case with things we don't commonly
> need. (Like the metadata, thread, and GC stuff) PMCs are 40 bytes on my
> PPC system. Too much cache fluff.
Me2. The macro stuff should be easy, it's all in popj.h and most are
macros already.
Additionally for such *big* changes in infrastructure it would be a
really good thing to have a *microparrot*. Only some PMCs (Hash, Array,
Int, Num, String) minimum infra structure, cut down VTABLE for only very
basic things.
This would of course not run tests but would be a valuable program to
check different deep core changes faster without really big patches to
the whole and everything.
leo