Formal Parameters To While Block

1 view
Skip to first unread message

Joshua Gatcomb

unread,
Apr 26, 2005, 11:24:41 AM4/26/05
to perl6-l...@perl.org
<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

unread,
Apr 26, 2005, 11:37:51 AM4/26/05
to Joshua Gatcomb, perl6-l...@perl.org
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

unread,
Apr 26, 2005, 9:48:14 AM4/26/05
to perl6-l...@perl.org
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

unread,
Apr 30, 2005, 8:24:32 AM4/30/05
to Luke Palmer, Perl6 Language List
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

unread,
Apr 30, 2005, 12:06:32 PM4/30/05
to Aaron Sherman, Perl6 Language List
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

unread,
Apr 30, 2005, 6:14:24 PM4/30/05
to Luke Palmer, Joshua Gatcomb, perl6-l...@perl.org
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

unread,
Apr 30, 2005, 10:24:14 PM4/30/05
to Autrijus Tang, Joshua Gatcomb, perl6-l...@perl.org

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

unread,
May 1, 2005, 4:37:28 AM5/1/05
to Luke Palmer, Joshua Gatcomb, perl6-l...@perl.org
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

unread,
May 1, 2005, 5:05:03 AM5/1/05
to Luke Palmer, Juerd, Joshua Gatcomb, perl6-l...@perl.org
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

unread,
May 1, 2005, 3:17:38 AM5/1/05
to Juerd, Joshua Gatcomb, perl6-l...@perl.org
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

unread,
May 1, 2005, 3:25:35 AM5/1/05
to Juerd, Joshua Gatcomb, perl6-l...@perl.org
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

unread,
May 1, 2005, 6:24:27 AM5/1/05
to Luke Palmer, perl6-l...@perl.org
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

unread,
May 2, 2005, 3:54:07 PM5/2/05
to Perl6 Language List
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

unread,
May 2, 2005, 5:51:40 PM5/2/05
to perl6-l...@perl.org
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

Reply all
Reply to author
Forward
0 new messages