Re: Array variables as formal parameters ???

[TSa]

HaloO,

John M. Dlugosz wrote:
Now back to straightening out my misconceptions about scalars _always_ 
holding item containers.  If $x is bound to an Array, for example, the 
compiled code can't be doing the indirection innately.


So it follows that the method forwarding is a property of the object 
that the method is originally called on.  That is, the Scalar (and any 
"tied" item container implementations) are written to forward all 
methods to the contained object.  The compiler sees $x.foo() and doesn't 
know anything about $x other than that it's some object, so it codes a 
message dispatch to it.  If $x holds a normal object, the foo method 
gets called via the normal dispatching rules.  But Scalar implements 
something that catches all methods and forwards them to the contained item.


===>Right?


I think that the implementation type of a Scalar can be compiled away
in almost all cases that involve getting the value. And even in lvalue
usage the only thing worth an actual runtime container is the type
constraint closure to call prior to storing the rvalue. So after a
$x = @a the scalar just contains the ID of the array object.



That would imply that if a scalar happened to contain another scalar, e.g.
   my $x = Scalar.new;
($x is bound to a Scalar which contains a Scalar which contains undef)
then any method called on $x would trigger the same behavior when the 
contained object gets it, and be forwarded all the way down, no matter 
how many Scalars I nested in this manner.


Hmm, I think the Scalar class should not be available for generic
instanciation. Scalar variables are handled through built-in features
of the underlying engine and are optimized heavily. Arrays are handled
by the same built-in mechanism, that is e.g. registers in Parrot.


So how does VAR work?  It can't just wrap another level around the 
original object to cancel out the automatic indirection.  It can't tell 
the compiler to generate different code, since the code knows nothing 
about this interesting property of scalars.  Instead it must return a 
proxy that knows how to trigger the actual methods on the scalar, 
avoiding the forwarding behavior of normal method calls.


===>   Is that right?


I would say no. The VAR instructs the compiler to use a special
interface of the underlying engine facility. The interesting thing
is that one needs VAR($x).readonly but can use @a.readonly directly.
I would opt for VAR(@a).readonly for symmetry. Or actually this VAR
interface should be all caps. Why should the Array class support a
.readonly method in the first place? The compiler knows the readonly
status of all variables from their lexically available definition!
So does the programmer if she bothers to look them up.


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

Re: Array variables as formal parameters ???

[TSa]

HaloO,

John M. Dlugosz wrote:
I'm assuming that the container defines what item assignment means.  At 
the very least, it will have the STORE method.  But I want to have 
infix:<=> definable in general without having to make it masquerade as 
an Item Container.


I strongly agree with that. It should not be the case that an assignment

   $x = $y;

is compiled down to

   $x.STORE($y.FETCH);

That is, the assignment is a mere syntactic device. The above procedure
should be wrapped in the default implementation

   multi infix:<=> (Any $lhs is rw, Any $rhs)
   {
  $x.STORE($y.FETCH);
   }

Note that due to contravariance the type constraint of $lhs should
actually be the bottom type not Any. OTOH rw is invariant in general.
Only here in assignment the $lhs is write-only. But Perl 6 hasn't
specced that trait on parameters.

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

Re: Array variables as formal parameters ???

[John M. Dlugosz]

Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:

On May 23, 2009 11:26:16 pm John M. Dlugosz wrote:
  

 > From whence did it get its Item container?

OK, my brain made a wrong turn some time on Tuesday.

Let me review the basics.

 From S02:
|$x| may be bound to any object, including any object that can be bound

to any other sigil.

Perl variables have two associated types: their "value type" and their
"implementation type".
Value type = "of", implementation type is the type of the container itself.

my $spot is Scalar; # this is the default


I think (that I may be getting out of my depth here) that the implementation 
type refers to the container at a deeper level.  That is, Scalar is a Perl 
container and not a Java nor Ruby container, which allows having objects from 
different languages (with their different semantics) in a single application.


  
That's right.  The way I learned it (and I worry about these 
early-learned principles being out of date!) is that using something 
other than the default Scalar class is like "tieing" in Perl 5.  You 
create your own item container that (presumably, following Perl 5's 
names) implements STORE and FETCH.  That could be a foreign variable I 
suppose.


If you wrote a class MyScalar, it could, for example, access the Windows 
"registry" when accessed, or automatically read or update a value from a 
GUI form.



 From S03:

A new form of assignment is present in Perl 6, called /binding/, used in
place of typeglob assignment. It is performed with the |:=| operator.
Instead of replacing the value in a container like normal assignment, it
replaces the container itself. For instance:

my $x = 'Just Another';
my $y := $x;
$y = 'Perl Hacker';


At first, I thought that this was a aliasing mechanism, but now I worry that 
this is how we have to assign non-Perl variables in a Perl application.  That 
is, the semantics of assignment differ depending the container type.


  
I'm assuming that the container defines what item assignment means.  At 
the very least, it will have the STORE method.  But I want to have 
infix:<=> definable in general without having to make it masquerade as 
an Item Container.





 From S12:

Method calls on mutable scalars always go to the object contained in the
scalar (autoboxing value types as necessary):

$result = $object.doit();
$length = "mystring".codes;

Method calls on non-scalar variables just calls the |Array|, |Hash| or

|Code| object bound to the variable:

$elems = @array.elems;
@keys  = %hash.keys;
$sig   = &sub.signature;

Use the prefix |VAR| macro on a scalar variable to get at its underlying

|Scalar| object:

if VAR($scalar).readonly {...}

||

So, if you say

my $x;

then $x is bound to a newly-created Scalar (not worrying about
conflating the name the Role and the concrete type at this point).

my $x = 'Just Another';

Now the "item assignment" operates on the container, storing the Str
instance within it.  $x is bound to a container, and the container
contains (only) one Str instance.


Rephrasing:  $x is a Perl container holding a Str object whose content 
(value?) is 'Just Another'.
  

Agree.  Scalar is a type of item container.

  

Basically, I was thinking that scalar variables always are bound to item
containers which contain the actual value.  In fact, this was originally
drilled into me:  containers vs values!  That variables always directly
hold some kind of container.  I suppose that's been changed at some
point, perhaps long ago, but the synopses didn't dissuade me from that
early belief.


I don't think it has been changed, I think that if you don't understand how 
"tie" is implemented in Perl5 (which is referenced heavily in the synopsis), 
then it is easy to miss the distinctions being made.  (It doesn't help that 
the Implementation type is in the middle of a bunch of "higher level" types).


  
Taken literally, it has:  "$x may be bound to any object, including any 
object that can be bound to any other sigil." 

That means that $x may be bound to an item container containing some 
other object, or may be bound directly to some other kind of object.  
That's my fundamental understanding at this point.  Unless something 
*really*strange* has become of "item container" ... (Larry, please?)

Anyway, as for your (Henry) example from Rakudo:

my $x = 1, 2, 3;

According to the synopses, this should be analogous to the previous
example, where $x now is bound to an item that contains a Capture
containing 3 Ints.

Assuming Capture vs Array is simply out of date implementation, just
focus on the parameter passing.  $x is bound to a Scalar.  But What I
Mean is for the formal parameter @y to get bound to the item in the
container, the list of Ints.

===>How does that happen?


The "List prefix precedence" section of Synopsis 3 says that it returns a list.  
It goes on a bit about t

Re: Array variables as formal parameters ???

[Henry Baragar]

On May 23, 2009 11:26:16 pm John M. Dlugosz wrote:
>  > From whence did it get its Item container?
>
> OK, my brain made a wrong turn some time on Tuesday.
>
> Let me review the basics.
>
>  From S02:
> |$x| may be bound to any object, including any object that can be bound
>
> to any other sigil.
>
> Perl variables have two associated types: their "value type" and their
> "implementation type".
> Value type = "of", implementation type is the type of the container itself.
>
> my $spot is Scalar; # this is the default
>
I think (that I may be getting out of my depth here) that the implementation 
type refers to the container at a deeper level.  That is, Scalar is a Perl 
container and not a Java nor Ruby container, which allows having objects from 
different languages (with their different semantics) in a single application.

>
>  From S03:
>
> A new form of assignment is present in Perl 6, called /binding/, used in
> place of typeglob assignment. It is performed with the |:=| operator.
> Instead of replacing the value in a container like normal assignment, it
> replaces the container itself. For instance:
>
> my $x = 'Just Another';
> my $y := $x;
> $y = 'Perl Hacker';
>
At first, I thought that this was a aliasing mechanism, but now I worry that 
this is how we have to assign non-Perl variables in a Perl application.  That 
is, the semantics of assignment differ depending the container type.

>  From S12:
>
> Method calls on mutable scalars always go to the object contained in the
> scalar (autoboxing value types as necessary):
>
> $result = $object.doit();
> $length = "mystring".codes;
>
> Method calls on non-scalar variables just calls the |Array|, |Hash| or
>
> |Code| object bound to the variable:
>
> $elems = @array.elems;
> @keys  = %hash.keys;
> $sig   = &sub.signature;
>
> Use the prefix |VAR| macro on a scalar variable to get at its underlying
>
> |Scalar| object:
>
> if VAR($scalar).readonly {...}
>
> ||
>
> So, if you say
>
> my $x;
>
> then $x is bound to a newly-created Scalar (not worrying about
> conflating the name the Role and the concrete type at this point).
>
> my $x = 'Just Another';
>
> Now the "item assignment" operates on the container, storing the Str
> instance within it.  $x is bound to a container, and the container
> contains (only) one Str instance.
>
Rephrasing:  $x is a Perl container holding a Str object whose content 
(value?) is 'Just Another'.

> Basically, I was thinking that scalar variables always are bound to item
> containers which contain the actual value.  In fact, this was originally
> drilled into me:  containers vs values!  That variables always directly
> hold some kind of container.  I suppose that's been changed at some
> point, perhaps long ago, but the synopses didn't dissuade me from that
> early belief.
>
I don't think it has been changed, I think that if you don't understand how 
"tie" is implemented in Perl5 (which is referenced heavily in the synopsis), 
then it is easy to miss the distinctions being made.  (It doesn't help that 
the Implementation type is in the middle of a bunch of "higher level" types).

>
> Anyway, as for your (Henry) example from Rakudo:
>
> my $x = 1, 2, 3;
>
> According to the synopses, this should be analogous to the previous
> example, where $x now is bound to an item that contains a Capture
> containing 3 Ints.
>
> Assuming Capture vs Array is simply out of date implementation, just
> focus on the parameter passing.  $x is bound to a Scalar.  But What I
> Mean is for the formal parameter @y to get bound to the item in the
> container, the list of Ints.
>
> ===>How does that happen?
>
The "List prefix precedence" section of Synopsis 3 says that it returns a list. 
 
It goes on a bit about the "contortions" that must be done to do this.

>
> Now back to straightening out my misconceptions about scalars _always_
> holding item containers.  If $x is bound to an Array, for example, the
> compiled code can't be doing the indirection innately.
>
> So it follows that the method forwarding is a property of the object
> that the method is originally called on.  That is, the Scalar (and any
> "tied" item container implementations) are written to forward all
> methods to the contained object.  The compiler sees $x.foo() and doesn't
> know anything about $x other than that it's some object, so it codes a
> message dispatch to it.  If $x holds a normal object, the foo method
> gets called via the normal dispatching rules.  But Scalar implements
> something that catches all methods and forwards them to the contained item.
>
> ===>Right?
>
Not quite (I think).  As mentioned above, I think that the Scalar is the the 
thing that knows how/which dispatch to use.

> That would imply that if a scalar happened to contain another scalar, e.g.
> my $x = Scalar.new;
> ($x is bound to a Scalar which contains a Scalar which contains undef)
> then an

Re: Array variables as formal parameters ???

[John M. Dlugosz]

Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:


Good question, since Nil does Positional, as evidenced by rakudo:
> say Nil ~~ Positional
1
Should report this as a bug?

Henry

  



At the very least, it is the most simple test case for Nil.  Should be 
in the test suite.

Re: Array variables as formal parameters ???

[Henry Baragar]

On May 23, 2009 11:31:35 pm John M. Dlugosz wrote:
> Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:
> >>>   > sub f2 (@y) {say @y.WHAT; say +...@y}; f2(Nil);
> >>>
> >>>   Array()
> >>>   1
> >>
> >> Why doesn't +...@y produce 0, not 1?  It's an empty list.
> >
> > From rakudo:
> > > sub f2 (@y) {say @y[0]}; f2(Nil);
> >
> > Nil()
> >
> > Henry
>
> Uh, @y is an Array of one item, that one item being Nil.
>
> I think the intent was to be an empty list.  Nil is not supposed to go
> into lists, but to become nothing when used in such a way.  Wrapping Nil
> into a list when it wasn't a list at all to begin with is totally
> missing the point.  And where did the wrapping Array come from?  
>
Good question, since Nil does Positional, as evidenced by rakudo:
> say Nil ~~ Positional
1
Should report this as a bug?

Henry

> At its
> simplest, Nil is an object whose Positional personality shows an empty
> list, and that's what the @ variable uses.
>
> --John

-- 

Henry Baragar
Instantiated Software
416-907-8454 x42

Re: Array variables as formal parameters ???

[John M. Dlugosz]

Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:

> sub f2 (@y) {say @y.WHAT; say +...@y}; f2(Nil);

Array()
1
  

Why doesn't +...@y produce 0, not 1?  It's an empty list.


From rakudo:
> sub f2 (@y) {say @y[0]}; f2(Nil);
Nil()

Henry

  


Uh, @y is an Array of one item, that one item being Nil.

I think the intent was to be an empty list.  Nil is not supposed to go 
into lists, but to become nothing when used in such a way.  Wrapping Nil 
into a list when it wasn't a list at all to begin with is totally 
missing the point.  And where did the wrapping Array come from?  At its 
simplest, Nil is an object whose Positional personality shows an empty 
list, and that's what the @ variable uses.


--John

Re: Array variables as formal parameters ???

[John M. Dlugosz]

> From whence did it get its Item container?


OK, my brain made a wrong turn some time on Tuesday.

Let me review the basics.

From S02:

|$x| may be bound to any object, including any object that can be bound 
to any other sigil.


Perl variables have two associated types: their "value type" and their 
"implementation type".

Value type = "of", implementation type is the type of the container itself.

   my $spot is Scalar; # this is the default


From S03:

A new form of assignment is present in Perl 6, called /binding/, used in 
place of typeglob assignment. It is performed with the |:=| operator. 
Instead of replacing the value in a container like normal assignment, it 
replaces the container itself. For instance:


   my $x = 'Just Another';
   my $y := $x;
   $y = 'Perl Hacker';

From S12:

Method calls on mutable scalars always go to the object contained in the 
scalar (autoboxing value types as necessary):


   $result = $object.doit();
   $length = "mystring".codes;

Method calls on non-scalar variables just calls the |Array|, |Hash| or 
|Code| object bound to the variable:


   $elems = @array.elems;
   @keys  = %hash.keys;
   $sig   = &sub.signature;

Use the prefix |VAR| macro on a scalar variable to get at its underlying 
|Scalar| object:


   if VAR($scalar).readonly {...}

||

So, if you say

   my $x;

then $x is bound to a newly-created Scalar (not worrying about 
conflating the name the Role and the concrete type at this point).


   my $x = 'Just Another';

Now the "item assignment" operates on the container, storing the Str 
instance within it.  $x is bound to a container, and the container 
contains (only) one Str instance.


Basically, I was thinking that scalar variables always are bound to item 
containers which contain the actual value.  In fact, this was originally 
drilled into me:  containers vs values!  That variables always directly 
hold some kind of container.  I suppose that's been changed at some 
point, perhaps long ago, but the synopses didn't dissuade me from that 
early belief.



Anyway, as for your (Henry) example from Rakudo:

   my $x = 1, 2, 3;

According to the synopses, this should be analogous to the previous 
example, where $x now is bound to an item that contains a Capture 
containing 3 Ints.


Assuming Capture vs Array is simply out of date implementation, just 
focus on the parameter passing.  $x is bound to a Scalar.  But What I 
Mean is for the formal parameter @y to get bound to the item in the 
container, the list of Ints. 


===>How does that happen?


Now back to straightening out my misconceptions about scalars _always_ 
holding item containers.  If $x is bound to an Array, for example, the 
compiled code can't be doing the indirection innately.


So it follows that the method forwarding is a property of the object 
that the method is originally called on.  That is, the Scalar (and any 
"tied" item container implementations) are written to forward all 
methods to the contained object.  The compiler sees $x.foo() and doesn't 
know anything about $x other than that it's some object, so it codes a 
message dispatch to it.  If $x holds a normal object, the foo method 
gets called via the normal dispatching rules.  But Scalar implements 
something that catches all methods and forwards them to the contained item.


===>Right?

That would imply that if a scalar happened to contain another scalar, e.g.
   my $x = Scalar.new;
($x is bound to a Scalar which contains a Scalar which contains undef)
then any method called on $x would trigger the same behavior when the 
contained object gets it, and be forwarded all the way down, no matter 
how many Scalars I nested in this manner.


So how does VAR work?  It can't just wrap another level around the 
original object to cancel out the automatic indirection.  It can't tell 
the compiler to generate different code, since the code knows nothing 
about this interesting property of scalars.  Instead it must return a 
proxy that knows how to trigger the actual methods on the scalar, 
avoiding the forwarding behavior of normal method calls.


===>   Is that right?

Thanks for your help everyone.  I hope to give back just as much, once 
I've caught back up.  In any case, what I learn I will document for all 
who come later.


--John

Re: Array variables as formal parameters ???

[Henry Baragar]

On May 23, 2009 04:19:53 pm John M. Dlugosz wrote:
> > @y just means "the argument must do the Positional role", so it's a
> > looser constraint than "is Array". Equivalent is more like:
> >
> >sub f2(Positional $x) { }
> >
> > Thanks,
> >
> > Jonathan
>
> I'm finding a difference in how a Positional is "bound to" a plain item
> variable.
> If the paramter-argument bond is shown as:
>
> my $x := @A;
>
>
> how can the Item variable "really" bond directly to the Positional
> object?  It doesn't have STORE and FETCH methods.  The item variable
> forwards methods to the contained item, and a directly-bonded Array does
> not.
>
If you think of parameters as being slots and the type information as being 
conditions on the objects being put into the slot, then an object is allowed 
to be put into a slot only if it meets those conditions.  Once the subroutine 
starts to run, then it uses the passed in object directly (e.g. the @A), but 
with its own name (e.g. $x):  no additional containers.

> I think I'm assuming more is (can be) happening at compile time.
> The delegation would have to be handled at run-time, rather than as
> something the compiler knows about?
>
Defining the constraints happens at compile time, but everything else happens 
at run time (including checking the constraints).  For example (from rakudo):

> sub f1(@y) {say @y.WHAT}; my $x = 1, 2, 3; f1($x); $x = 5; f1($x)
Array()
Parameter type check failed; expected something matching Positional() 
but got 
something of type Int() for @y in call to f1
in sub f1 (:1)
called from Main (:1)
>

Regards,
Henry


Regards,
Henry

> Thanks,
> --John

-- 

Henry Baragar
Instantiated Software
416-907-8454 x42

Re: Array variables as formal parameters ???

[John M. Dlugosz]

Jonathan Worthington jonathan-at-jnthn.net |Perl 6| wrote:

Hi,

Little clarification...

Henry Baragar wrote:
I think that in your "Example 1", that you may be making too making 
too much of a distinction between "$a" and "@a".  That is:

sub f2(@y) {...}
has exactly the same signature as sub f2($x is Array) {...}
In other words, they both take a single argument that must be of type 
Array.
  
@y just means "the argument must do the Positional role", so it's a 
looser constraint than "is Array". Equivalent is more like:


   sub f2(Positional $x) { }

Thanks,

Jonathan



I'm finding a difference in how a Positional is "bound to" a plain item 
variable.

If the paramter-argument bond is shown as:

my $x := @A;


how can the Item variable "really" bond _directly_ to the Positional 
object?  It doesn't have STORE and FETCH methods.  The item variable 
forwards methods to the contained item, and a directly-bonded Array does 
not.


I think I'm assuming more is (can be) happening at compile time.
The delegation would have to be handled at run-time, rather than as 
something the compiler knows about? 


Thanks,
--John

Re: Array variables as formal parameters ???

[Henry Baragar]

On May 23, 2009 04:10:49 pm John M. Dlugosz wrote:
> Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:
> > I think that in your "Example 1", that you may be making too making too
> > much of a distinction between "$a" and "@a".  That is:
> > sub f2(@y) {...}
> > has exactly the same signature as
> > sub f2($x is Array) {...}
> > In other words, they both take a single argument that must be of type
> > Array. Hence, @y and $x work the same "beneath the surface" and there is
> > no extra level of indirection.
>
> But... $x has an Item container, and @y doesn't !
>
From whence did it get its Item container?

> > Now that we are viewing parameters as providing constraints rather than
> > contexts, we get a different view on your "Example 2".  I made your
> > example
> >
> > more concrete and ran it through rakudo, yielding:
> > > sub f1 ($x) {say $x.WHAT}; f1(Nil);
> >
> > Nil()
> >
> > > sub f2 (@y) {say @y.WHAT; say +...@y}; f2(Nil);
> >
> > Array()
> > 1
>
> Why doesn't +...@y produce 0, not 1?  It's an empty list.
From rakudo:
> sub f2 (@y) {say @y[0]}; f2(Nil);
Nil()

Henry

> And if the argument types are viewed as constraints only, denoting
> whether the call is acceptable but not changing anything about it, and
> f2 is written as way above, the two functions would produce the same
> output.  Clearly they're not.
>
> > See, no problems with f2().
>
> Good.  Thanks.

-- 

Henry Baragar
Instantiated Software
416-907-8454 x42

Re: Array variables as formal parameters ???

[John M. Dlugosz]

Henry Baragar Henry.Baragar-at-instantiated.ca |Perl 6| wrote:
I think that in your "Example 1", that you may be making too making too much 
of a distinction between "$a" and "@a".  That is:

sub f2(@y) {...}
has exactly the same signature as 
	sub f2($x is Array) {...}
In other words, they both take a single argument that must be of type Array. 
Hence, @y and $x work the same "beneath the surface" and there is no extra 
level of indirection.


  

But... $x has an Item container, and @y doesn't !




Now that we are viewing parameters as providing constraints rather than 
contexts, we get a different view on your "Example 2".  I made your example 
more concrete and ran it through rakudo, yielding:

> sub f1 ($x) {say $x.WHAT}; f1(Nil);
Nil()
> sub f2 (@y) {say @y.WHAT; say +...@y}; f2(Nil);
Array()
1
>
  

Why doesn't +...@y produce 0, not 1?  It's an empty list.
And if the argument types are viewed as constraints only, denoting 
whether the call is acceptable but not changing anything about it, and 
f2 is written as way above, the two functions would produce the same 
output.  Clearly they're not. 





See, no problems with f2().
  


Good.  Thanks.

  

Re: Array variables as formal parameters ???

[Jonathan Worthington]

Hi,

Little clarification...

Henry Baragar wrote:
I think that in your "Example 1", that you may be making too making too much 
of a distinction between "$a" and "@a".  That is:

sub f2(@y) {...}
has exactly the same signature as 
	sub f2($x is Array) {...}
In other words, they both take a single argument that must be of type Array. 

  
@y just means "the argument must do the Positional role", so it's a 
looser constraint than "is Array". Equivalent is more like:


   sub f2(Positional $x) { }

Thanks,

Jonathan

Re: Array variables as formal parameters ???

[Henry Baragar]

On May 22, 2009 06:55:49 pm John M. Dlugosz wrote:
> Please take a look at
> .

I think that in your "Example 1", that you may be making too making too much 
of a distinction between "$a" and "@a".  That is:
sub f2(@y) {...}
has exactly the same signature as 
sub f2($x is Array) {...}
In other words, they both take a single argument that must be of type Array. 

Hence, @y and $x work the same "beneath the surface" and there is no extra 
level of indirection.

Now that we are viewing parameters as providing constraints rather than 
contexts, we get a different view on your "Example 2".  I made your example 
more concrete and ran it through rakudo, yielding:
> sub f1 ($x) {say $x.WHAT}; f1(Nil);
Nil()
> sub f2 (@y) {say @y.WHAT; say +...@y}; f2(Nil);
Array()
1
>
See, no problems with f2().

Regards,
Henry


> I started working through how the detailed behavior of the Capture and
> passing rules need to work, and I ran into something that startled me.
> There's no examples in S06 of formal parameters, other than the special
> *...@slurp form, that is declared with a sigil other than a $.  For example,
>
> sub f1 ($x, @y, @z) { ... }
>
> Before I get any farther with this line of thought, I want to know if
> I'm missing something important.
>
> Thanks,
> --John

-- 

Henry Baragar
Instantiated Software
416-907-8454 x42

Array variables as formal parameters ???

[John M. Dlugosz]

Please take a look at 
.
I started working through how the detailed behavior of the Capture and 
passing rules need to work, and I ran into something that startled me.  
There's no examples in S06 of formal parameters, other than the special 
*...@slurp form, that is declared with a sigil other than a $.  For example,


   sub f1 ($x, @y, @z) { ... }

Before I get any farther with this line of thought, I want to know if 
I'm missing something important.


Thanks,
--John