Formal Parameters To While Block

[Joshua Gatcomb]

<as it appears the email I sent before subscribing is being held and I
am impatient, I have subsequently subscribed and am resending from a
different address>

All:
Please forgive me, but I have only recently started
following the language side of p6 after spending a
fair amount of time with Parrot. Last night I
installed Pugs and wrote my first p6 code:

http://perlmonks.org/index.pl?node_id=451398

Reading S04, it seems that there are no implicit
blocks around control structures, so p5 code like:

while ( my @array = $ref->() ) { ... }

would scope my @array appropriately, it will not in p6

The solution is formal parameters. The trouble is I
can't seem to find a good example in S04 that matches
what I am trying to do.

while $ref() -> @array { ... }

is what I think it might be modeling it after the for
loop, but the closest thing I see in while is:

while =$*IN -> $line {...}

I am happy to write tests to get the appropriate
functionality in Pugs, but I am not sure what is
appropriate???

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

[Luke Palmer]

Joshua Gatcomb writes:
> The solution is formal parameters. The trouble is I
> can't seem to find a good example in S04 that matches
> what I am trying to do.
>
> while $ref() -> @array { ... }

We're thinking at the moment that `while` will probably look like this:

sub statement:<while> (&cond is lazy, &block) {
my $cond;

again:
$cond = &cond();
return $cond unless $cond;
&block.arity ? &block($cond) : &block;
goto again;
}

That does pose a problem with:

given $foo {
until $_.leaf {
^process; # uh oh, means $foo.leaf.process
$_ = ^next;
}
}

Using the "best so far" proposal for calling methods on $_. Allow this
to serve as an example for how it will look in real code.

Luke

[Joshua Gatcomb]

All:
Please forgive me, but I have only recently started
following the language side of p6 after spending a
fair amount of time with Parrot. Last night I
installed Pugs and wrote my first p6 code:

http://perlmonks.org/index.pl?node_id=451398

Reading S04, it seems that there are no implicit
blocks around control structures, so p5 code like:

while ( my @array = $ref->() ) { ... }

would scope my @array appropriately, it will not in p6

The solution is formal parameters. The trouble is I

can't seem to find a good example in S04 that matches
what I am trying to do.

while $ref() -> @array { ... }

is what I think it might be modeling it after the for
loop, but the closest thing I see for while is:

while =$*IN -> $line {...}

I am happy to write tests to get the appropriate
functionality in Pugs, but I am not sure what is
appropriate???

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

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Aaron Sherman]

On Tue, 2005-04-26 at 09:37 -0600, Luke Palmer wrote:

> We're thinking at the moment that `while` will probably look like this:
>
> sub statement:<while> (&cond is lazy, &block) {

[...]

Just curious, why a sub and not a macro?

> That does pose a problem with:
>
> given $foo {
> until $_.leaf {
> ^process; # uh oh, means $foo.leaf.process
> $_ = ^next;
> }
> }

Ok, I'm lost. What's a unary "^"?

In S03, I see "$^<identifier>", "^^", "^..", "..^", and "^..^", but no
"^<identifier>".

Best I can figure is that's a "placeholder sub"? So you're expecting a
named parameter of type Code called "process"? No, that can't be right,
can it?

[Luke Palmer]

Aaron Sherman writes:
> On Tue, 2005-04-26 at 09:37 -0600, Luke Palmer wrote:
>
> > We're thinking at the moment that `while` will probably look like this:
> >
> > sub statement:<while> (&cond is lazy, &block) {
> [...]
>
> Just curious, why a sub and not a macro?

Didn't need a macro. statement:<while> will probably end up generating
parrot code directly, but this is a possible non-macro implementation.

> > That does pose a problem with:
> >
> > given $foo {
> > until $_.leaf {
> > ^process; # uh oh, means $foo.leaf.process
> > $_ = ^next;
> > }
> > }
>
> Ok, I'm lost. What's a unary "^"?

Whoops. I think I forgot to say that I was experimenting with the
half-proposed unary ^meth for $_.meth.

Luke

[Autrijus Tang]

On Tue, Apr 26, 2005 at 09:37:51AM -0600, Luke Palmer wrote:
> Joshua Gatcomb writes:
> > The solution is formal parameters. The trouble is I
> > can't seem to find a good example in S04 that matches
> > what I am trying to do.
> >
> > while $ref() -> @array { ... }
>
> We're thinking at the moment that `while` will probably look like this:
>
> sub statement:<while> (&cond is lazy, &block) {

Ooh! Did I see a "is lazy" here? Thanks, implemented. :-)

/Autrijus/

[Luke Palmer]

Yeah, "is lazy" should be fine for now. The feature is definitely
there, but it might end up being called something different. "is
braceless"?

Luke

[Juerd]

Luke Palmer skribis 2005-04-26 9:37 (-0600):

> sub statement:<while> (&cond is lazy, &block) {

How does that handle

for { closure }, { closure } -> { ... }

and why? :)

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

[Juerd]

Luke Palmer skribis 2005-05-01 1:17 (-0600):
> Umm... maybe I'm totally misunderstanding you, but I think it doesn't,
> since I'm implementing statement:<while>, not statement:<for>.

Sorry, I wasn't clear enough. How would the same "is lazy" thing be
useful with "for", given this example?

[Luke Palmer]

Juerd writes:
> Luke Palmer skribis 2005-04-26 9:37 (-0600):
> > sub statement:<while> (&cond is lazy, &block) {
>
> How does that handle
>
> for { closure }, { closure } -> { ... }
>
> and why? :)

Umm... maybe I'm totally misunderstanding you, but I think it doesn't,

since I'm implementing statement:<while>, not statement:<for>.

Luke

[Luke Palmer]

Juerd writes:
> Luke Palmer skribis 2005-05-01 1:17 (-0600):
> > Umm... maybe I'm totally misunderstanding you, but I think it doesn't,
> > since I'm implementing statement:<while>, not statement:<for>.
>
> Sorry, I wasn't clear enough. How would the same "is lazy" thing be
> useful with "for", given this example?

Ahh. It wouldn't. Which is a pretty good example of why "is lazy" is
the wrong name.

"is lazy" is used for the condition of "while", the right side of || and
&&, etc. It is for when you pass a closure without putting braces
around it.

Well, almost like that. We still have to handle:

while my $line = =<> {...}
# $line still in scope

Which is different from:

&statement:<while>({ my $line = =<> }, {...});
# $line not in scope

Anyway, "for" doesn't need "is lazy", because it simply evaluates the
list it is given and iterates over it. The fact that evaluating the
list may be a no-op because of laziness is unrelated to "is lazy"
(another hint that it's the wrong name).

Luke

[Brent 'Dax' Royal-Gordon]

On 5/1/05, Luke Palmer <lu...@luqui.org> wrote:
> Anyway, "for" doesn't need "is lazy", because it simply evaluates the
> list it is given and iterates over it. The fact that evaluating the
> list may be a no-op because of laziness is unrelated to "is lazy"
> (another hint that it's the wrong name).

To start off the name game:

`is deferred`? `is closure`, `is coderef`, `is sub`? `is condition`?

--
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker

"I used to have a life, but I liked mail-reading so much better."

[Larry Wall]

On Sat, Apr 30, 2005 at 10:06:32AM -0600, Luke Palmer wrote:
: Aaron Sherman writes:
: > On Tue, 2005-04-26 at 09:37 -0600, Luke Palmer wrote:
: >
: > > We're thinking at the moment that `while` will probably look like this:
: > >
: > > sub statement:<while> (&cond is lazy, &block) {
: > [...]
: >
: > Just curious, why a sub and not a macro?
:
: Didn't need a macro. statement:<while> will probably end up generating
: parrot code directly, but this is a possible non-macro implementation.

Your sub declaration there strikes me as just an inside-out macro
declaration, insofar as it won't work unless the declaration is
visible as a predeclaration in the lexical scope, just like a macro.
It might be permissible as a form of syntactic sugar if we were
trying to encourage people to write braceless code, but I'm not
sure we want to encourage that. In fact, I'm pretty sure we don't.
Maybe "is BRACELESSANDIREALLYMEANIT" or some such... :-)

So maybe instead of sub that is told to be braceless on some arguments,
what we really want is a macro that can be told evaluate some of its
arguments normally rather than returning an AST. Not sure how this
links into the macro syntax though.

Larry

[Larry Wall]

On Sat, Apr 30, 2005 at 08:24:14PM -0600, Luke Palmer wrote:
: Yeah, "is lazy" should be fine for now. The feature is definitely

: there, but it might end up being called something different. "is
: braceless"?

I think "is braceless" is better, if only because it's longer.
Though I still suspect it's really a macro in disguise, and we
might be better off declaring it as a macro but with some kind of
magic that blockifies its arguments rather than ASTifying it.

Or maybe we should invent the "submacro", whose block is assumed to be
the runtime implementation, and all the thunks come in preblockfied,
at least for args declared with &. Then we get the advantages of the
sub form while documenting that you can't take a runtime link to the
macro and expect it to influence the parser.

Larry