Re: Binding to a sub's return value

[Brent 'Dax' Royal-Gordon]

Juerd <[EMAIL PROTECTED]> wrote:
> := is the thing that implements subroutine arguments. Ask yourself the
> same question with:
>
> sub another_routine ($rv) {
> ...
> }
> another_routine(some_routine());
>
> I'd expect $rv to be an alias to a copy of $foo's value, 42.

Really?  Because the default parameter binding is constant reference,
last I checked.

I actually like that answer.  It means that you can bind the return
value, but you can't mutate it, unless the function 'is rw'.  (And
perhaps you could mark it as 'is copy' and 'is ref', too...)

--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker

Re: Scoping of $/

[Larry Wall]

On Tue, May 10, 2005 at 05:24:30PM -0400, Rick Delaney wrote:
: On Tue, May 10, 2005 at 06:20:44AM -0600, Luke Palmer wrote:
: > Yeah, they're lexical, just like in Perl 5.
: 
: Not just like Perl 5, I hope.  If it was then the above would print
: "d".

Yes, Perl 5 actually uses an autolocalizing form of dynamic scoping
for the current successful match, but *only* if there was a successful
match.  We're intentionally breaking that.

Larry

Re: Scoping of $/

[Rick Delaney]

On Tue, May 10, 2005 at 06:20:44AM -0600, Luke Palmer wrote:
> On 5/10/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> > Hi,
> > 
> >   sub foo() {

say $1;# undef?

> > "abc" ~~ /^(.)/;   # $1 now "a"
> >   }
> > 
> >   sub bar() {
> > "def" ~~ /^(.)/;   # $1 now "d"
> > foo();
> > say $1;# Outputs "d"
> >   }
> > 
> >   bar();
> > 
> >   # Correct (I hope so)?
> 
> Yeah, they're lexical, just like in Perl 5.

Not just like Perl 5, I hope.  If it was then the above would print
"d".

-- 
Rick Delaney
[EMAIL PROTECTED]

Re: Binding to a sub's return value

[Aaron Sherman]

On Tue, 2005-05-10 at 15:52, Joshua Gatcomb wrote:
> I am wondering what the proper behavior of binding to a sub's return
> value should be
> 
> sub some_routine {
> my $foo = 42;
> return $foo;
> }
> my $rv := some_routine();
> 
> Should $rv be bound to $foo or to a copy of $foo?  I ask because with
> state() and closures, it makes a difference since the value can
> change.

Yes, so let's pose an easy, full example with a result we can point at:

my $x = 1;
my $y := (->{$x}).();
$x++;
say $y;

Ok, so clearly that prints 1 or 2 (the first person to say it's a
junction gets the mean look ;)

Some questions I'd add to yours:

  * We discussed auto-closurizing := statements before, so when does
that happen vs. performing the operation and taking the value
exactly?
  * If the above prints 2, then how do you return a value that is a
constant "safely"? Do you need to explicitly invoke a cloning
operation on it?
  * How can I talk you out of it? ;-)

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

Re: Binding to a sub's return value

[Juerd]

Joshua Gatcomb skribis 2005-05-10 15:52 (-0400):
> sub some_routine {
> my $foo = 42;
> return $foo;
> }
> my $rv := some_routine();
> Should $rv be bound to $foo or to a copy of $foo?  I ask because with
> state() and closures, it makes a difference since the value can
> change.

:= is the thing that implements subroutine arguments. Ask yourself the
same question with:

sub another_routine ($rv) {
...
}
another_routine(some_routine());

I'd expect $rv to be an alias to a copy of $foo's value, 42.

UNLESS some_routine is lvalue (which in this case it is not), in which
case, I'd expect $rv to be an alias to $foo itself

> sub some_rourtine {
> state $foo = 42;
> return $foo++;
> }

rvalue some_rourtine: copy 42

lvalue some_rourtine: error, ++ doesn't return an lvalue
(although prefix ++ probably could).


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Binding to a sub's return value

[Joshua Gatcomb]

I am wondering what the proper behavior of binding to a sub's return
value should be

sub some_routine {
my $foo = 42;
return $foo;
}
my $rv := some_routine();

Should $rv be bound to $foo or to a copy of $foo?  I ask because with
state() and closures, it makes a difference since the value can
change.

sub some_rourtine {
state $foo = 42;
return $foo++;
}

My apologies if this has been previously discussed or is documented
somewhere.  I am still playing catch up.  Ok, ok - it's true - I am
looking for a little instant gratification.

Cheers,
Joshua Gatcomb
a.k.a. L~R

Re: Circular dereference?

[Juerd]

Thomas Sandlaß skribis 2005-05-10 19:02 (+0200):
> Juerd wrote:
> > No, again, please do not make the mistake of thinking VALUES have
> > identity. VARIABLES (containers) do. A reference points to a container,
> > never to a value directly.
> I don't consider it a mistake. 

That is a problem.

> So, you dany identity to "fat" values like database connections or GUI
> objects?

Objects are references to containers. Primitive values, like strings and
numbers are not objects. They can be used as objects, though.

Assignment copies. When that is a reference, the reference is copied. It
still points to the same thing. Thus, $obj2 = $obj1 DOES NOT clone, even
though $str2 = $str1 DOES clone the string.

Containers have identity. Objects are references to containers. The
identity of an object is that of the referred container, not the
container that holds the reference.

Database connections and GUI objects are objects, and as such have their
own containers, which have identities.

> > Try in perl (5) the following code:
> > my ($xx, $yy) = \($x, $y);
> Actually I still wonder how equal or different assignment
> with = of a ref produced by \ is from binding with :=.

t is because you lack understanding of the system of names,
containers and values that Perl uses. As long as you think values have
identity and containers are always implicit, you cannot understand the
difference between aliasing and referencing. Or the difference between 4
and $foo = 4, for that matter.

> The second line above e.g. should produce a ref to a list value
> (undef, undef), right?

List references do not exist (array references do, but that is entirely
besides the point). \($x, $y) in Perl 5 returns the same as (\$x, \$y).

I'm sorry I assumed you knew Perl 5, I'll try to explain my code next
time.

> Then this value shall be used to initializes the content of whatever
> the names $xx and $yy refer to. So, why don't the references not just
> vanish and we get to independent undef values stored in $xx and $yy?

Why should references "just vanish"? That's not a likely course of
action a reference will take. A reference only vanishes when something
else replaces it, or it is garbage collected.

> I.e. do you expect $x = 5 have an effect on the value of $xx?

No. $xx's value still points to the same container, the container that
$x also points to.

name  :  container  :  value
..:.:..
  : :
$xx > SCALAR  > (REF)
  : : |
  : +-+
  : V   :
$x  > SCALAR  >   5
  : :
  : :

Or, using the boxes metaphor, where each box is a container, and in it
is drawn its value, and names are outside of boxes

 +- $xx +- $x
 |  |
 V  V
+-++---+
| reference -> | 5 |   
+-++---+

Now, if you do either $x-- or $$xx--, only the value of the container
previously holding 5 changes:

name  :  container  :  value
..:.:..
  : :
$xx > SCALAR  > (REF)
  : : |
  : +-+
  : V   :
$x  > SCALAR  >   4
  : :
  : :

boxes:

 +- $xx +- $x
 |  |
 V  V
+-++---+
| reference -> | 4 |   
+-++---+

If $xx was an alias for $x, thus "$xx := $x" instead of "$xx = \$x", it
would be like this:

name  :  container  :  value
..:.:..
  : :
$xx +   :
  : |   :
  : V   :  
  :   SCALAR  > 123
  : ^   :  
  : |   :
$x  +   :
  : :
  : :

(I moved $x to another line to show that $x and $xx are both equal in
"rank": none is the "real" name, they're both real.)

boxes:

 +- $x  +- $xx
 |  |
 V  V
+-+
| 123 |   
+-+
  
> > Declaration and := bind names to containers.
> I disagree.

Do you disagree that they do, or that they should?

Because they do do.

> Names are a compile time concept 

Well, not strictly.

> and access to the namepace level is restricted after compilation.

Not at all, in Perl.

> Some languages like C++ and Java actually compile the namespace almost
> completely away.

Perl is not "some languages", and certainly not C++ or Java.

> So Declaration is mostly a way to talk to the compiler while := is a
> runtime operator.

Perl knows many runtimes, of which some are often called compile time.

> > A reference points to a container.
> Well, can we agree that a reference is a means to retrieve a value?

No. It's a means of pointing to a container. To get tha

Re: Circular dereference?

[Thomas Sandlaß]

Juerd wrote:
No, again, please do not make the mistake of thinking VALUES have
identity. VARIABLES (containers) do. A reference points to a container,
never to a value directly.
I don't consider it a mistake. So, you dany identity to "fat" values
like database connections or GUI objects?

This is something that doesn't change from Perl 5 to Perl 6.
Why?
Try in perl (5) the following code:
my ($x, $y);
my ($xx, $yy) = \($x, $y);
Actually I still wonder how equal or different assignment
with = of a ref produced by \ is from binding with :=.
The second line above e.g. should produce a ref to a list
value (undef, undef), right? Then this value shall be used to
initializes the content of whatever the names $xx and $yy
refer to. So, why don't the references not just vanish and
we get to independent undef values stored in $xx and $yy?
I.e. do you expect $x = 5 have an effect on the value of $xx?

There are names, containers and values.
I agree.

Declaration and := bind names to containers.
I disagree. Names are a compile time concept and access to
the namepace level is restricted after compilation. Some
languages like C++ and Java actually compile the namespace
almost completely away. So Declaration is mostly a way to
talk to the compiler while := is a runtime operator.

Assignment copies values.
I agree.

Containers aren't copied.
I agree. Their content is retrieved and copied to a new container.

A reference points to a container.
Well, can we agree that a reference is a means to retrieve a value?

A name points to a container.
Yes, but see above for compile time.

A reference is a value.
I agree.

The reference isn't to $y's container's value, but to the container.
Regardless of its value. It is also not to the name $y.
I don't see much use in pointing to a container because the interest
is in the value unless to want to go in an explicit pointer arithmetic
scheme like C++. Does \$v + 1 mean something different than $v + 1?
To me it does at most create a level of indirection that is traced to
the value when the args for + are prepared.
How about the following idea to distinguish between read and write
refs? I would actually call the former View!
$x = 3;
$y = 5;
$rr  = \$y; # read ref (or view)
$wr :=  $x; # write ref
say $rr; # prints 5
$rr = 7;
say $y;  # prints 5 because $rr doesn't trace the view but discards it
 # as any other non-referential value
say $wr; # prints 3
$wr = 9;
say $x;  # prints 9 because $wr traces down to lowest container/ref and
 # redirects it (my view) or exchanges the value (juerd's view)
Comments?
--
TSa (Thomas Sandlaß)

Re: adverbial blocks: description and examples requested

[Terrence Brannon]

Ashley, this is a great post. I have included it almost verbatim in my
p6 talk I'm giving tomorrow at our Perl Monger's meeting:

   http://www.metaperl.com/talks/p6/hangman-elucidated/slide6.html

I hope you don't mind.

> On 5/5/05, Terrence Brannon <[EMAIL PROTECTED]> wrote:
>> I was looking at a line in the hangman program:
>> 
>>   @letters == @solution.grep:{ $_ ne '' };
>> 
>> and was told that I was looking at an adverbial block.
>> 
>> But I don't understand what that is and could not find a description
>> and examples in a reverse search on dev and nntp.perl.org.
>
> Methods with arguments require parens. However, the block to grep
> isn't I an argument. It's describing the manner in which the
> array will be grepped... that's an adverb to grep.
>
> So, why are the parens required on methods? Take the following if statements:
>
> if @foo.shift { ... }
>
> if @foo.grep { ... }   # grep doesn't get the block
>
> To make things clear, methods without parens are assumed to take no
> arguments. In order to pass a block to the above grep, you either need
> to use @foo.grep({ $^a <=> $^b}) or the adverbial colon:
>
> if @foo.grep:{$^a <=> $^b} { ... }
>
> Ashley Winters

-- 
Carter's Compass: I know I'm on the right track when,
   by deleting something, I'm adding functionality.

Re: adverbial blocks: description and examples requested

[Terrence Brannon]

Luke Palmer <[EMAIL PROTECTED]> writes:

> On 5/5/05, Terrence Brannon <[EMAIL PROTECTED]> wrote:
>> I was looking at a line in the hangman program:
>>
>>   @letters == @solution.grep:{ $_ ne '' };
>>
>> and was told that I was looking at an adverbial block.
>
> The adverbial block is what you're giving to `if` when you say:
>
> if $foo { ... }

But no colon is used in this case. Is that consistent?

-- 
Carter's Compass: I know I'm on the right track when,
   by deleting something, I'm adding functionality.

split /(..)*/, 1234567890

[Autrijus Tang]

In Pugs, the current logic for array submatches in split() is
to stringify each element, and return them separately in the
resulting list.  To wit:

pugs> split /(..)*/, 1234567890
('', '12', '34', '56', '78', '90')

Is this sane?

Thanks,
/Autrijus/


pgpoNrOaK2bLb.pgp
Description: PGP signature

Re: Nested captures

[Uri Guttman]

> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:

  DC> rule mv { $lastcmd:=(mv)  $:=[  ]+  $:= }
  DC> rule cp { $lastcmd:=(cp)  $:=[  ]+  $:= }
  DC> sub lastcmd { return $lastcmd }
  DC> }
  DC> while shift ~~ m// {
  DC> say "From: @{$}";
  DC> say "  To: $";
  DC> }
  >> since files and dirs are internal aliases (their names are in <>),
  >> shouldn't those match accesses be $/ and $/?

  DC> Sure. Just as $42 is a shorthand for $/[42], so too $ is a
  DC> shorthand for $/.

but then what about the different index bases for $42 and $/[42]? i
don't think that has been resolved (nor has mixing the $1.1 and $1[1]
syntaxes). 

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

[PROPOSAL] call syntax abstraction

[Leopold Toetsch]

Second attempt and cc'ed to other Perl lists too.
 Original Message 
Subject: [PROPOSAL] call syntax abstraction
Date: Tue, 03 May 2005 13:58:14 +0200
Comments welcome,
leo
=head1 TITLE

Calling convention abstraction

=head1 ABSTRACT

The current Parrot calling conventions as described in
F are not covering major
parts of our target languages. The scheme isn't extensible and uses a
lot of resources (opcodes, runloop dispatches, registers) to achieve
it's work.

This proposal describes an abstract, extensible, and more efficient
alternative to pdd03.

=head1 DESCRIPTIOON

All the work related to function calls is done by dedicated opcodes.
No registers are reserved currently, but during the transition phase
and possibly thereafter, registers are/may be used. This will be
specified after the implementation of the compatibly scheme is
completed.

=head2 Opcodes

New B opcodes:

  op args(inconst STR, ...)# call arguments
  op results(inconst STR, ...) # get return results
  op params(inconst STR, ...)  # function parameters
  op returns(inconst STR, ...) # function return
  op yields(inconst STR, ...)  # coroutine yield values

The constant STR argument is a signature string denoting successional
arguments to the opcode.

An opcode to define return context:

  op results(inconst INT)  # define return context

And:

  op argcI(out INT)# amount of I args or returns
  op argcP(out INT)# amount of P
  op argcS(out INT)# amount of S
  op argcN(out INT)# amount of N

=head2 Call opcodes cleanup

While it's not strictly needed it's highly desirable to get rid of the
current implicit register usage in call related opcodes.

See also: I for an older discussion on that topic.

  op invoke(in PMC, in PMC)# $1 = sub/method, $2 = continuation
  op invoke(in STR, in PMC)# invocants are covered by args

  op invokecc(in PMC)  # $1 = sub/meth, create continuation [1]
  op invokecc(in STR)  # invocants are covered by args

  op tailcall(in PMC)  # $1 = sub/method
  op tailcall(in STR)

[1] if the called thing isa NCI PMC the creation of the continuation
is skipped.

=head2 Signature chars - current calling scheme coverage

  I... INTVAL var
  i... INTVAL constant
  N,n,S,s,P,p   ... analog
  O... single PMC invocant
  @... call: flatten array to next args

=head2 Signature chars - possible extensions

  @... call: flatten
   params/results: make array
  %... call: flatten **kw hash
   params(/results): make hash
  kX   ... call: named arguments (key => X)
  OO   ... call: 2 PMC invocants
  :... call: end of invocants marker
  nX   ... params: default arguments (name = X)
  ?... params: optional part follows
  =P   ... params/returns: clone P  (or maybe cP)
  &... ruby code block

E.g.

  args "PP", P10, P20   # function call
  args "OIS", P5, I10, S30  # method call
  args "P:IS", P5, I10, S30 # same method call
  args "P@", P0, P1 # flatten P1, args become P0, *P1
  args "%", P2  # P2 is a **kw hash
  args "kPkP", "$a", P0, "$b", P1   # named arguments "$a" => P0, ...
  params "ni", "$i", 1  # default argument "$i" = 1
  params "P?PPP"# await 1 - 4 arguments passed in

=head2 Return context

  results 0  # void
  results 1  # 1 return result
  results n  # n return result
  results -1 # list context

As the I opcode goes before the call, we can attach a perlish
return context to the return continuation and make it available in the
called function.

=head2 Simple example

  .sub main @MAIN
args "IN", I16, N16[1]
invokecc "foo" [2]
results "I", I16   [3]
  .end

  .sub "foo"
 params "IN", I16, N16 [4]
 ...
 returns "I", 1[5]
  .end

=head2 Comparison with current syntax

  .sub main @MAIN
set I0, 1  [1]
set I1, 1
set I2, 0
set I3, 0
set I4, 1
set I5, I16
set N5, N16
set S1, "IN"
invokecc "foo" [2]
set I16, I5[3]
  .end

  .sub "foo"
set I16, I5[4}
set N16, N5
...
set I0, 1  [5]
set I1, 1
set I2, 0
set I3, 0
set I4, 0
set I5, 1
returncc
  .end

=head2 opcode and dispatch count comparison

  current scheme proposed scheme
  opcodes call/result   29  9
  dispatches10  3

  opcodes param/ret 25  7
  dispatches 9  2

  opcodes overall   54 16
  dispatches19  5

=head2 Example main

  .sub main @MAIN

params "@", P5# argv array like now
params

Re: Scoping of $/

[Luke Palmer]

On 5/10/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Hi,
> 
>   sub foo() {
> "abc" ~~ /^(.)/;   # $1 now "a"
>   }
> 
>   sub bar() {
> "def" ~~ /^(.)/;   # $1 now "d"
> foo();
> say $1;# Outputs "d"
>   }
> 
>   bar();
> 
>   # Correct (I hope so)?

Yeah, they're lexical, just like in Perl 5.

Luke

Scoping of $/

[Ingo Blechschmidt]

Hi, 
 
  sub foo() { 
"abc" ~~ /^(.)/;   # $1 now "a" 
  } 
 
  sub bar() { 
"def" ~~ /^(.)/;   # $1 now "d" 
foo(); 
say $1;# Outputs "d" 
  } 
 
  bar(); 
 
  # Correct (I hope so)? 
 
 
--Ingo 
 
--  
Linux, the choice of a GNU | Row, row, row your bits, gently down the 
generation on a dual AMD   | stream...   
Athlon!|  

Re: Nested captures

[Luke Palmer]

On 5/10/05, Aaron Crane <[EMAIL PROTECTED]> wrote:
> Damian Conway writes:
> > Just as $42 is a shorthand for $/[42], so too $ is a
> > shorthand for $/.
> 
> Isn't $42 a shorthand for $/[41] ?
> 
> I think that having 1-based digit-variables but 0-based array indexes on
> $/ is really confusing; mistakes of this sort seem to confirm my view.

Yeah, I'm pretty sure they should be consolidated somehow.  Of course
we could make $# zero-based.  But there are other possibilities:

* $/[0] is like $&, the full text of the match
* $/[0] is the name of the matching rule, like in P::RD

The latter isn't applicable everywhere, but I have to say that it was
pretty handy.  But I'm not sure I ever used its zeroth position to my
advantage, so it would probably be better of a method on $/.

The former case is actually quite elegant if we extend it to the new
matching semantics.  Consider:

"foobarbaz" ~~ / (foo (bar)) (baz) /

Then:

$/[0] eq "foobarbaz";
$/[1] is a match object
$/[1][0] eq "foobar"
$/[1][1][0] eq "bar"
$/[2][0] eq "baz"

So now we have the strigification behavior on $/: it just returns its
zeroth element.  The current meaning of $0 is now consistent and means
exactly the same thing it used to.

But I'm in the middle of a movie, so I haven't really thought through
the rest of it clearly.  I think it breaks down somewhat in the
presence of quantifiers.

Luk

Re: Nested captures

[Aaron Crane]

Damian Conway writes:
> Just as $42 is a shorthand for $/[42], so too $ is a
> shorthand for $/.

Isn't $42 a shorthand for $/[41] ?

I think that having 1-based digit-variables but 0-based array indexes on
$/ is really confusing; mistakes of this sort seem to confirm my view.

-- 
Aaron Crane

Re: Nested captures

[Damian Conway]

  DC>  rule mv { $lastcmd:=(mv)  $:=[  ]+  
$:= }
  DC>  rule cp { $lastcmd:=(cp)  $:=[  ]+  
$:= }
  DC>  sub lastcmd { return $lastcmd }
  DC>  }
  DC>  while shift ~~ m// {
  DC>  say "From: @{$}";
  DC>  say "  To: $";
  DC>  }
since files and dirs are internal aliases (their names are in <>),
shouldn't those match accesses be $/ and $/?
Sure. Just as $42 is a shorthand for $/[42], so too $ is a shorthand 
for $/.

Damian