Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

S6: Change in if syntax?

13 views
Skip to first unread message

Buddha Buck

unread,
Apr 11, 2003, 12:15:29 PM4/11/03
to perl6-l...@perl.org
Did I miss something and the if statement syntax changed, or is there a
typo in S6? (Or did I never understand the if statement syntax to begin
with, which is always a possiblity)

On page 2, discussing closure parameters, there is the example:

>
> sub limited_grep (Int $count, &block, *@list) {
> ...
> if block($nextelem) {...}
> ...
> }
>

I thought that the if statement syntax required parenthesis around the
condition, making that middle line:

if (block($nextelem)) {...}

So, are the parenthesis now optional, and if so... when did that happen?

Austin Hastings

unread,
Apr 11, 2003, 12:28:15 PM4/11/03
to Buddha Buck, perl6-l...@perl.org

Spot the 'C' programmer! Spot the 'C' programmer!

(Finally, it's not me for once... :-)

=Austin

Luke Palmer

unread,
Apr 11, 2003, 12:51:05 PM4/11/03
to bmb...@14850.com, perl6-l...@perl.org

Yes, they are now optional. We get this by DWIMming on whitespace
just a little bit.

There can now be no whitespace between a variable and its
subscript. So

my %hashy;
print %hashy {foo};

Is illegal. Therefore:

if %hashy { ... }

Is no longer ambiguous. I think it's brilliant... those parentheses
were so annoying.

if $a == 4 { ... }

Luke

Buddha Buck

unread,
Apr 11, 2003, 12:43:31 PM4/11/03
to Austin_...@yahoo.com, perl6-l...@perl.org

Hmmm, I would have thought my inner C programmer would have wanted to do

if (block($nextelem))
print "'tis true"; # single statement, no braces

But since I was accused of confusing C and perl, I decided to
double-check...

Camel III, page 113:

# The following statements may be used to control conditional and
# repeated execution of BLOCKs. (The LABEL portion is optional.)
#
# if (EXPR) BLOCK
# if (EXPR) BLOCK else BLOCK
# if (EXPR) BLOCK elsif (EXPR) BLOCK ...
# if (EXPR) BLOCK elsis (EXPR) BLOCK ... else BLOCK

So it looks like, at one time, the parenthesis were required.

Paul

unread,
Apr 11, 2003, 12:59:36 PM4/11/03
to Buddha Buck, Austin_...@yahoo.com, perl6-l...@perl.org
> Camel III, page 113:
>
> # The following statements may be used to control conditional and
> # repeated execution of BLOCKs. (The LABEL portion is optional.)
> #
> # if (EXPR) BLOCK
> # if (EXPR) BLOCK else BLOCK
> # if (EXPR) BLOCK elsif (EXPR) BLOCK ...
> # if (EXPR) BLOCK elsis (EXPR) BLOCK ... else BLOCK
>
> So it looks like, at one time, the parenthesis were required.

P5 still requires the parens.
P6 will not, but as Luke pointed out, doesn't let you put space between
a var and it's subscript.

So this is valid P5 but not P6:

if ( $foo {bar} # using whitespace to line up subscripts
or $piddle {far} ) { # for visual reasons, but parens required
boo();
}

and this (I think) is valid P6 but not P5:

if $foo{bar} or $piddle{far} { boo(); }


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

Brent Dax

unread,
Apr 13, 2003, 5:04:38 AM4/13/03
to Hod...@writeme.com, Buddha Buck, Austin_...@yahoo.com, perl6-l...@perl.org
Paul:
# if ( $foo {bar} # using whitespace to line up subscripts
# or $piddle {far} ) { # for visual reasons, but parens required
# boo();
# }

I would imagine (read: "hope") that the no-whitespace thing would be
tiebreaking rule, i.e. "if you can't tell, assume it's a block".

--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism


Damian Conway

unread,
Apr 13, 2003, 6:04:51 AM4/13/03
to perl6-l...@perl.org
Brent Dax wrote:

> Paul:
> # if ( $foo {bar} # using whitespace to line up subscripts
> # or $piddle {far} ) { # for visual reasons, but parens required
> # boo();
> # }
>
> I would imagine (read: "hope") that the no-whitespace thing would be
> tiebreaking rule, i.e. "if you can't tell, assume it's a block".

Nope. It's a hard-and-fast part of the syntax. Absolutely no whitespace in
variable accesses. Not under any circumstances. Never.

At least, not until you explicitly modify the grammar to allow it. ;-)

Damian

Paul

unread,
Apr 13, 2003, 10:07:03 PM4/13/03
to Brent Dax, Buddha Buck, Austin_...@yahoo.com, perl6-l...@perl.org

--- Brent Dax <bren...@cpan.org> wrote:
> Paul:
> # if ( $foo {bar} # using whitespace to line up subscripts
> # or $piddle {far} ) { # for visual reasons, but parens required
> # boo();
> # }
>
> I would imagine (read: "hope") that the no-whitespace thing would be
> tiebreaking rule, i.e. "if you can't tell, assume it's a block".

Ditto. Anybody know for sure?

Piers Cawley

unread,
Apr 22, 2003, 10:22:05 AM4/22/03
to Hod...@writeme.com, Brent Dax, Buddha Buck, Austin_...@yahoo.com, perl6-l...@perl.org
Paul <ydb...@yahoo.com> writes:

> --- Brent Dax <bren...@cpan.org> wrote:
>> Paul:
>> # if ( $foo {bar} # using whitespace to line up subscripts
>> # or $piddle {far} ) { # for visual reasons, but parens required
>> # boo();
>> # }
>>
>> I would imagine (read: "hope") that the no-whitespace thing would be
>> tiebreaking rule, i.e. "if you can't tell, assume it's a block".
>
> Ditto. Anybody know for sure?

Last time I looked it wasn't a tiebreaking rule, it was absolute. At
least, that was my understanding...

--
Piers

Paul

unread,
Apr 22, 2003, 11:03:57 AM4/22/03
to Piers Cawley, Brent Dax, Buddha Buck, Austin_...@yahoo.com, perl6-l...@perl.org
> >> # if ( $foo {bar} # whitespace to line up subscripts,
> >> # or $piddle {far} ) { # but parens required

> >> # boo();
> >> # }
> >>
> >> I would imagine (read: "hope") that the no-whitespace thing would
> >> be tiebreaking rule, i.e. "if you can't tell, assume it's a
block".
> >
> > Ditto. Anybody know for sure?
>
> Last time I looked it wasn't a tiebreaking rule, it was absolute. At
> least, that was my understanding...

Sadly, I believe you are correct. *Still* can't recall which apocolypse
that was, and haven't bothered looking. I can live with it. :/

I'm sure the other effects of twiddling the whitespace will be more
appreciated than this one will be mourned, though I have been known to
do a LOT of this sort of thing....

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

Michael Lazzaro

unread,
Apr 22, 2003, 12:37:50 PM4/22/03
to perl6-l...@perl.org

>>>> # if ( $foo {bar} # whitespace to line up subscripts,
>>>> # or $piddle {far} ) { # but parens required
>>>> # boo();
>>>> # }
>>>>
>>>> I would imagine (read: "hope") that the no-whitespace thing would
>>>> be tiebreaking rule, i.e. "if you can't tell, assume it's a
> block".
>>>
>>> Ditto. Anybody know for sure?

Absolutism was confirmed about a week ago:

On Sunday, April 13, 2003, at 03:04 AM, Damian Conway wrote:
> Nope. It's a hard-and-fast part of the syntax. Absolutely no
> whitespace in variable accesses. Not under any circumstances. Never.
>
> At least, not until you explicitly modify the grammar to allow it. ;-)
>
> Damian

But note that it probably isn't too bad, because I imagine you can
still use the method op (e.g. dot) to get that effect:

if ( $foo .{bar}
or $biddle .{bar} ) {...}

I'm pretty content with that, myself, in exchange for making the parens
optional for things like C<if>.

MikeL

Damian Conway

unread,
Apr 22, 2003, 6:27:58 PM4/22/03
to perl6-l...@perl.org
Piers Cawley wrote:

>>># if ( $foo {bar} # using whitespace to line up subscripts
>>># or $piddle {far} ) { # for visual reasons, but parens required
>>># boo();
>>># }
>>>
>>>I would imagine (read: "hope") that the no-whitespace thing would be
>>>tiebreaking rule, i.e. "if you can't tell, assume it's a block".
>>
>>Ditto. Anybody know for sure?
>
> Last time I looked it wasn't a tiebreaking rule, it was absolute. At
> least, that was my understanding...

It's absolute.

Best you can do is:

if $foo{bar}
or $piddle{far} {
boo();
}

However, whitespace *is* allowed inside subscripts (as in Perl 5):

if $foo{ bar }
or $foo{ semprini } {
boo();
}


Damian

Arcadi Shehter

unread,
Apr 22, 2003, 7:25:34 PM4/22/03
to Damian Conway, perl6-l...@perl.org
Damian Conway writes:
> Piers Cawley wrote:
>
> >>># if ( $foo {bar} # using whitespace to line up subscripts
> >>># or $piddle {far} ) { # for visual reasons, but parens required
> >>># boo();
> >>># }
> >>>
> >>>I would imagine (read: "hope") that the no-whitespace thing would be
> >>>tiebreaking rule, i.e. "if you can't tell, assume it's a block".
> >>
> >>Ditto. Anybody know for sure?
> >
> > Last time I looked it wasn't a tiebreaking rule, it was absolute. At
> > least, that was my understanding...
>
> It's absolute.
>
> Best you can do is:
>
> if $foo{bar}
> or $piddle{far} {
> boo();
> }
>

is the "space-eating-underscore" gone ????

if ( $foo _{bar} # using whitespace to line up subscripts
or $piddle _{far} ) { # for visual reasons, but parens required

Brent Dax

unread,
Apr 22, 2003, 8:15:37 PM4/22/03
to Damian Conway, perl6-l...@perl.org
Damian Conway:
# Piers Cawley wrote:
# > Last time I looked it wasn't a tiebreaking rule, it was
# absolute. At
# > least, that was my understanding...
#
# It's absolute.
#
# Best you can do is:
#
# if $foo{bar}
# or $piddle{far} {
# boo();
# }

Which of the following (if any) is valid?

$foo.{bar}
$foo .{bar}
$foo. {bar}

Damian Conway

unread,
Apr 22, 2003, 8:28:45 PM4/22/03
to perl6-l...@perl.org
Brent Dax asked:

> Which of the following (if any) is valid?
>
> $foo.{bar}
> $foo .{bar}
> $foo. {bar}

The first certainly is and in fact, since there's no ambiguity, I believe all
three are.

Except, of course, when they're interpolated into a string, when only the
first interpolates as a hash access (the other two just interpolate $foo).

Damian

Larry Wall

unread,
Apr 22, 2003, 9:51:15 PM4/22/03
to perl6-l...@perl.org
On Wed, Apr 23, 2003 at 10:28:45AM +1000, Damian Conway wrote:
: Brent Dax asked:

:
: >Which of the following (if any) is valid?
: >
: > $foo.{bar}
: > $foo .{bar}
: > $foo. {bar}
:
: The first certainly is and in fact, since there's no ambiguity, I believe
: all three are.

I think the third should be illegal (until someone defines themselves
a postfix:. operator).

Larry

Brent Dax

unread,
Apr 23, 2003, 2:54:51 AM4/23/03
to Larry Wall, perl6-l...@perl.org
Larry Wall:
# On Wed, Apr 23, 2003 at 10:28:45AM +1000, Damian Conway wrote:
# : Brent Dax asked:
# :
# : >Which of the following (if any) is valid?
# : >
# : > $foo.{bar}
# : > $foo .{bar}
# : > $foo. {bar}
# :
# : The first certainly is and in fact, since there's no
# ambiguity, I believe
# : all three are.
#
# I think the third should be illegal (until someone defines
# themselves a postfix:. operator).

If you aren't going to require a lack of whitespace around e.g.
C<infix:+>, why require it around C<infix:.>?

Or are you suggesting that this is really a restriction on
C<circumfix:{}>? If so, why forbid it around C<circumfix:{}> but not
around C<circumfix:[]> or C<circumfix:()>? (Or is it forbidden around
them too?)

Perhaps we need a new type of operator, along the lines of C<indexer:>,
which takes two arguments (object and index) and has the whitespace
restrictions on it?

Luke Palmer

unread,
Apr 23, 2003, 3:09:53 AM4/23/03
to bren...@cpan.org, la...@wall.org, perl6-l...@perl.org
> Larry Wall:
> # On Wed, Apr 23, 2003 at 10:28:45AM +1000, Damian Conway wrote:
> # : Brent Dax asked:
> # :
> # : >Which of the following (if any) is valid?
> # : >
> # : > $foo.{bar}
> # : > $foo .{bar}
> # : > $foo. {bar}
> # :
> # : The first certainly is and in fact, since there's no
> # ambiguity, I believe
> # : all three are.
> #
> # I think the third should be illegal (until someone defines
> # themselves a postfix:. operator).
>
> If you aren't going to require a lack of whitespace around e.g.
> C<infix:+>, why require it around C<infix:.>?

This is perfectly legal:

$foo . bar;

> Or are you suggesting that this is really a restriction on
> C<circumfix:{}>? If so, why forbid it around C<circumfix:{}> but not
> around C<circumfix:[]> or C<circumfix:()>? (Or is it forbidden around
> them too?)

I think it is. That way we can have:

print (myfunc $a, $b), "\n"

and

print(myfunc $a, $b), "\n"

Do different things, and have them both do what you expect. It's
still up in the air, though.

No postfix operators can have whitespace before them, just like in
Perl 5. And since {} is really a postfix, not a circumfix (that's
code and hash constructor) operator, it creates no exception.

I also don't think it's possible to write these such subscripting
operators with operator: notation (not to say it's impossible to add
new subscripters...)

> Perhaps we need a new type of operator, along the lines of C<indexer:>,
> which takes two arguments (object and index) and has the whitespace
> restrictions on it?

Kind of a postfix: circumfix: combination. I wonder whether it'll be
a common enough operation to define new subscripters to add this new
type. Probably not.

OTOH, it might be common enough that people override these operators
to allow it. I'd call it C<subscript:>, though.

Luke

Paul

unread,
Apr 23, 2003, 9:41:09 AM4/23/03
to Larry Wall, perl6-l...@perl.org

Just for clarity's sake, the first and second still mean differing
things, right? Isn't this a case where the whitespace is significant?

Michael Lazzaro

unread,
Apr 23, 2003, 12:42:58 PM4/23/03
to Hod...@writeme.com, perl6-l...@perl.org

On Wednesday, April 23, 2003, at 06:41 AM, Paul wrote:
>> : >Which of the following (if any) is valid?
>> : >
>> : > $foo.{bar}
>> : > $foo .{bar}
>> : > $foo. {bar}
>>
>> I think the third should be illegal (until someone defines themselves
>> a postfix:. operator).
>> Larry
>
> Just for clarity's sake, the first and second still mean differing
> things, right? Isn't this a case where the whitespace is significant?

No, they're the same. You can specify a whitespace in front of the
method-call operator (the dot), so you can do any of these:

$foo.bar


$foo .bar
$foo . bar

$foo.[ $i ]
$foo .[ $i ]

$foo.{ $k }
$foo .{ $k }

It's that way so that you can split long expressions onto multiple
lines at the C<.>, e.g.

$obj
.do_something_important( blah, blah, blah )
.do_something_to_the_result_of_that( fee, fie, foh, fum );

Only question is whether you can say
$foo . { $k }

e.g. put the space inbetween the dot and the [] or {}.

I'm fine with saying you can't, because it's not necessary. You want
to split lines before the dot, but splitting lines after the dot is
just obfuscatory:

$obj.do_something_important( blah, blah, blah ).
{ $key };

I mean, if you do that, you're just being cruel.

IN FACT, I'd like to see

$foo . bar

be similarly illegal, because it similarly gains you nothing.

MikeL

Paul

unread,
Apr 23, 2003, 1:49:54 PM4/23/03
to Michael Lazzaro, perl6-l...@perl.org

I might disagree with the style assumptions.
I'd say that if you could put the space before and behind that a dot
hanging out on the end of a line like that is an indicator of
continuation, as is added indentation on the next line. I'd *rather*
see the dot exposed and hanging that way, though I'm not really that
picky about it.

My reasoning being that

$foo.bar()
.baz();

is reasonably clear, but

$foo.bar() .
baz() ;

looks *wierder*, and so draws the readers attention to it to ask "wait,
what's going on here?" If their view is scrolled so that they can only
see the first of either of those two pairs of lines, which is more
clearly demonstrating that there is something else important coming
below? In the first, the only clue is the *lack* of a semicolon, but
that could also be because it's written

method x ($foo: *@more) {
do_this_prep(*@more);
$foo.bar()
}

I'd say no semicolon was a bad idea there, but isn't it acceptable?

I'd also like to comment that I am amused such a small matter can
elicit so many lines of text from me in response. :)

Paul

Arcadi Shehter

unread,
Apr 29, 2003, 10:37:10 AM4/29/03
to Damian Conway, perl6-l...@perl.org

I was reading
http://www.linux-mag.com/downloads/2003-04/perl6/03.04.perl6.2.txt
and in particular , this

print -sum(@probs >>*<< >>log<<(@probs))/log(2);

And I have several questions

* are all these are correct ( and equivalent ) ?

@y = >>log<< @x # (1)
@y = >>log<<(@x) # (2)
@y = >>log<< .(@x) # (3)
@y = log >>.<< (@x)# (4)
@y = log >>.(@x)<< # (5) wild and probably wrong guess

it seems that there is no way to insert space between vectorized sub
and its argument if only 2 is OK.

But log is unary operator so probably (1) and (2) apply to it for that
reason .

What if I have a sub accepting 2 scalar args

sub pow($base , $exp=2) {...}

will both these work ?:

#list of squares
@y = >>pow<<(@base,$exp)
#or:
@y = pow >>.<< (@base,$exp)


#list of powers
@y = >>pow<<($base,@exp)

Also :
is these equivalent to @c = @a >>+<< @b :

@c = >>infix:+<< (@a,@b)

or it should be

@c = >>infix:+<< .(@a,@b)

or it should be

@c = infix:>>+<< .(@a,@b)


arcadi

Piers Cawley

unread,
May 5, 2003, 9:14:30 AM5/5/03
to arcadi shehter, Damian Conway, perl6-l...@perl.org
arcadi shehter <fear...@figaro.weizmann.ac.il> writes:

> I was reading
> http://www.linux-mag.com/downloads/2003-04/perl6/03.04.perl6.2.txt
> and in particular , this
>
> print -sum(@probs >>*<< >>log<<(@probs))/log(2);
>
> And I have several questions
>
> * are all these are correct ( and equivalent ) ?
>
> @y = >>log<< @x # (1)
> @y = >>log<<(@x) # (2)
> @y = >>log<< .(@x) # (3)
> @y = log >>.<< (@x)# (4)
> @y = log >>.(@x)<< # (5) wild and probably wrong guess
>
> it seems that there is no way to insert space between vectorized sub
> and its argument if only 2 is OK.
>
> But log is unary operator so probably (1) and (2) apply to it for that
> reason .

Personally I'd argue that you should only be able to vectorize
things that are used in 'operator form'. So I'd say that only 1 and
2 are definitely legal. I'm wary of >>.<< being considered legal
syntax though.

> What if I have a sub accepting 2 scalar args
>
> sub pow($base , $exp=2) {...}
>
> will both these work ?:
>
> #list of squares
> @y = >>pow<<(@base,$exp)
> #or:
> @y = pow >>.<< (@base,$exp)
>
>
> #list of powers
> @y = >>pow<<($base,@exp)

I would hope not. But:

@y = >>pow.assuming(exp => $exp)<<(@base);

and

@y = >>pow.assuming(base => $base)<<(@exp)

should work...

> Also :
> is these equivalent to @c = @a >>+<< @b :
>
> @c = >>infix:+<< (@a,@b)
>
> or it should be
>
> @c = >>infix:+<< .(@a,@b)
>
> or it should be
>
> @c = infix:>>+<< .(@a,@b)

Ick... I haven't a clue. The infix:>>+<< option looks the most
promising though, since it implies that one could write:

multi infix:+ ($a, $b) {...}
multi infix:>>+<< ($a, @b) {...}
multi infix:>>+<< (@a, $b) {...}
multi infix:>>+<< (@a, @a) {...}

But I'm not sure either way here, after all, in most cases you could
probably abstract out the vectorizing behaviour:

multi outfix:>><< (&op, $arg) { &op($arg) }
multi outfix:>><< (&op, @arg) { map {&op($_)} @arg }
multi outfix:>><< (&op, $a1, @a2) { map { &op($a1, $_) } @a2 }
...

Hmm... I'm pretty sure those signatures are wrong though...


--
Piers

Arcadi Shehter

unread,
May 8, 2003, 1:38:27 PM5/8/03
to Piers Cawley, Damian Conway, perl6-l...@perl.org
Piers Cawley writes:
>
> multi infix:+ ($a, $b) {...}
> multi infix:>>+<< ($a, @b) {...}
> multi infix:>>+<< (@a, $b) {...}
> multi infix:>>+<< (@a, @a) {...}

reading this I have this strange thought :
currently "for" is a sub acsepting array and block

sub for ( @a, &block ) { ... }

but we can equally make it multimethod , so that it will reduce the
burden currently put on "zip"-like functions


multi for ( @a, @b , &block($,$) ) {
for zip(@a,@b), &block
}

multi for ( @a, @b , @c , &block($,$,$) ) {
for zip(@a,@b,@c), &block
}

...

multi for ( @a, $b , &block($,$) ) {
for @a -> $a { &block( $a,$b ) }
}
...

and then :

for @a, @b -> { pow( $^a, $^b ) }

for @base, $exp -> { pow( $^base, $^exp ) }

but then I could go as far as ( but probably I shouldnt go there )

multi infix:--> (@a, &op($)) {
@a ==>map &op
}

and then :

$e = -sum ( @p -->{$_*log$_} );

>
> But I'm not sure either way here, after all, in most cases you could
> probably abstract out the vectorizing behaviour:
>
> multi outfix:>><< (&op, $arg) { &op($arg) }
> multi outfix:>><< (&op, @arg) { map {&op($_)} @arg }
> multi outfix:>><< (&op, $a1, @a2) { map { &op($a1, $_) } @a2 }

> ....


>
> Hmm... I'm pretty sure those signatures are wrong though...
>
>
> --
> Piers


arcadi


0 new messages