Steve Fink writes: > Ok, I'm back to argument passing. I'm starting a new thread because > I'm lazy and I have to scroll back too far in my mailer to see the old > arg passing thread. :-) And yes, most of this message should also be > on -languages.
Which it now is. Although, there are some internals issues, too, so I wonder how we can do this. How about, when someone responds to either an -internals- or a -language-specific question, he directs it only to the appropriate list. > Could somebody tell me where I go wrong: > > If you have a prototype > sub f ($a, $b, $c) { ... } > then you should pass $a in P5, $b in P6, etc. So the code will look > like: > .param $a > .param $b > .param $c > > If you declare a sub without a prototype, it should default to ([EMAIL PROTECTED]). Yep. > A slurpy array parameter puts its corresponding arguments in a list > context, which is the same as a flattening context. This is stated in > E6 and S6, though not in A6 as I read it (but it doesn't disagree > either.) > > Let's add a prototype-less sub for use in discussion: > sub g { ... } > > Is there any way to create a prototype that, when called with any > number of array variables, would pass all of the arrays as objects? > So, for example, f(@x, @y, @z) would do the right thing for exactly > three arrays, but couldn't handle f(@x,@y,@z,@w). g(@x, @y, @z) seems > to flatten all of them together. I'm sure something like > g([EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]) would work, but what if I > want to do the call without > backslashes? This was described in A6. It goes: sub g([EMAIL PROTECTED] is context(Scalar)) {...} > The calls f(1, 2, 3) and g(1, 2, 3) should both generate > .arg 1 > .arg 2 > .arg 3 > ...except instead of constant ints, you'd probably need PMCs. But constant ones :-) > Splatted array params are aliases to the actual args. So > > sub h ([EMAIL PROTECTED]) { @params[1] = 'tuna!'; } > h($x, $y, $z); > > should set $y to 'tuna!'. No, it should give an error. Parameters are declared constant by default. You'd have to: sub h ([EMAIL PROTECTED] is rw) { @params[1] = 'tuna!' } How to make the distinction between a constant array and an array of constants is still unclear to me. > Would h(@x) set @x[1] to 'tuna!'? If so, then does > > h(@x, $y) > > change $y's value depending on the number of elements in @x? Ouch. Yeah, I guess so. I don't expect to see C<[EMAIL PROTECTED] is rw> a whole lot, but that is a bit of a pickle to implement. > It seems that @params is either a magical array where lookups trigger > a runtime computation of where that index would be found in the > original argument list, or it is an array of references to either > variables or <variable,key> pairs, and all of those references are > built at runtime immediately when the call is made. (Which rather > defeats the default laziness of arrays.) Actually, "proxies" might be > a more accurate term. You should be able to pass @params into another > function just like any other array, or do > > $gloof = (rand(100) < 30) ? @params : @normal_array; > > Or maybe h(@x) does NOT set @x[1] to 'tuna!'? > > Ok, the whole aliasing thing was something of a tangent. Back to f() > and h(), which are really f($,$,$) and h(*@). > > I can use names to pass required arguments, but all positional args > must precede all named args. So then is this legal: > > f(1, 2, b => 1.5) > > or must all of the positional args referred to by named parameters > follow those passed positionally? (There are two orders -- argument > order and parameter order. In which of those two must all positionals > precede the named params?) Both. (In parameter order, named-only must come after positionals) So f(1, 2, b => 1.5) was correct. > In > > sub j($a, ?$b, *%c) { ... } > > can I actually pass %c after the rest of the params? If I call it with > > j(1, $blue => 'red') > > then does that compile down to > > .param 1 > .param named_arg_table > > ? How is the callee supposed to know whether the 2nd param is $b or > %c? What if $blue happened to be "b"? If $blue was 'b', then j would get $b to be 'red'. Run-time positionals are another one of those things I don't expect to see all that often (but that might be a different story in my code >:-). The real problem arises in: j(1, 2, $blue => 'red') If $blue happens to be 'b'. I think the behavior then would be $b gets 2, and %h gets { b => 'red' }. In particular, I think it's wrong to croak with an error here. > If I do it the other way around, > > .param named_arg_table > .param 1 > > then at least I can always assume the named args are passed first, and > use the arg count to directly determine whether $b was passed or not. > But then all Perl6 subroutines would have to take a named arg table as > their first argument, by convention, and cross-language calls would > need to be aware of this -- even when calling unprototyped. ("Oh, > yeah, if you're calling a Perl6 routine you have to pass an empty > hashtable as the first param.") > > I have a first cut at Perl6 parameter passing. [snip] Luke