http://qs1969.pair.com?node_id=279557


in reply to Exegesis 6 - Named binding

Simply because a pair has the same key value as one of the variables on the left side, it is assigned to that?
I believe this is so we have behaviour orthogonal to that of named sub/method/etc parameters. As you can pass named parameters into a sub and it will do the right thing e.g 
sub func(Int $this, Str $that) { ... }

func(279544, "a string");

## or with named parameters

func(that => 'thing you do', this => 0xdeadbeef);

[download]
So we don't need to maintain order of the arguments we pass in as perl6 will do the right thing and alias the arguments to correct positions in the parameter list. Now when we do named binding it's pretty much the same thing, but without the sub call e.g 
($this, $that) := ( 279544, 'a string' );

## or with named parameters

($this, $that) := (that => 'thing you do', this => 0xdeadbeef);

[download]
Also notice that both the parameter list and the named binding alias their arguments as well as putting the arguments in the right place.
Then simply because of my naming of the variables I assign to, I would get the reverse result?
If you're performing a simple assign, then yes, the reversing of the variables that are being to assigned to will get the reverse data (same as perl5). But of course if you bind instead and the return is a list of pairs then it should DTRT e.g 
sub &part(Selector $is_sheep, *@data) {
   ## body here
   return *%herd;
}
($goat, $sheep) = part Animal::Cat, @animals;

[download]
Now regardless of the order of the LHS, the values should be bound correctly as the flattening of %herd produces a list of pairs.
makes no sence to me either, unless a colon is missing as in
Indeed, because without the binding colon you don't get the named binding behaviour. I'll speculate that it'll empty out %details and then assign it whatever is on the RHS.
HTH

_________
broquaint

Disclaimer: IANAP6DG (I Am Not A Perl6 Design Guru ;)

Replies are listed 'Best First'.
Re: Re: Exegesis 6 - Named binding
by Cine (Friar) on Jul 31, 2003 at 13:23 UTC
    makes no sence to me either, unless a colon is missing as in
    Indeed, because without the binding colon you don't get the named binding behaviour. I'll speculate that it'll empty out %details and then assign it whatever is on the RHS.
    Well, there are two things it could do. Either it is the same as %details{who} = "me", %details{why} = $because, which would make sence because of the unary * operator or it would be the same as %details = ();%details{who} = "me", %details{why} = $because, but then what usage is the * operator?

    T I M T O W T D I
[reply]
[d/l]
[select]
      Either it is the same as %details{who} = "me", %details{why} = $because, which would make sence because of the unary * operator or it would be the same as %details = ();%details{who} = "me", %details{why} = $because
      The reason I suspect it to be behave like the latter is because the flattening behaviour of the * in this context. If we broke it down it might look something like this 
       %data = << why dunno who them where there which this >>;
*%data = ( who => 'me', why => 'because' );

## which if we expand the splat expands to (I think)

%data.kv = ( who => 'me', why => 'because' );

      [download]
      That of course assumes the kv method is lvaluable, but basically it looks like it's assigning all of %data to the RHS. Whereas with named binding it will just be the keys who and why which are bound, otherwise we assume that named binding behaviour is also used in straight assignments, which isn't the case. Again this is all speculation, but I'm hoping it's not too far off, or at least raising some interesting issues. Perhaps in this particular instance the splat is a no-op, or maybe it's a slurp and %data isn't run-over (but that would in turn make the assignment look like a right-to-left pipe ...).
      HTH

      _________
      broquaint

[reply]
[d/l]
        I still think its the former.
        Given that 
        %data = << why dunno who them where there which this >>;

        [download]
        I would assume that writing *%data in any context is equivalent to writing 
        (why => "dunno", who => "them", where => "there", which => "this")

        [download]
        So assuming we can use this as an lvalue, an assignment with a list of pairs to this would be the same as taking each pair and assigning it to the value with the specific key. So *%data = *%values should be compiled as 
        multi sub infix:=(List of Pair @assign is rw, List of Pair @values) re
+turns List of Pair {
  my %assign := *@assign;
  for @values {
     %assign{.key} = .value;
  }
  return *%assign;
}

        [download]
        Let me take another example and go back to part(). We could write: 
        my $fish = "hest";
($sheep, $goats, $fish) := part Animal::Cat, @animals;

        [download]
        So the question here is, is $fish eq "hest" after this, or undef?
        Alternatly we could have written 
        my $hest = "hest";
%result := ($sheep, $goats, fish => $hest) := part Animal::Cat, @anima
+ls;

        [download]
        Would that give the same result?

        Update: Forgot the multi keyword
        Update: As broquaint pointed out below, I forgot to use the binding operator as I indented to...
        Update: And the second example is completly bogus, because it would endeed result in a compile time error. Was 
        ($sheep, $goats, $fish => "hest") := part Animal::Cat, @animals;

        [download]




        T I M T O W T D I
[reply]
[d/l]
[select]
Re: Re: Exegesis 6 - Named binding
by Cine (Friar) on Aug 01, 2003 at 00:16 UTC
    I asked about this in #perl, and the consesus seems to be that it does not clear %details, because 
    sub part (Selector $is_sheep,
          Str *%labels = (sheep => "sheep", goats => "goats"),
          *@data
         ) returns List of Pair
{ ... }

    [download]
    would just do the wrong thing if called as part sheep=>"horse", Animal::Horse, @animals

    Update: Just to make it clear, I'm talking assignment here, not binding.



    T I M T O W T D I
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom