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?
Spot the 'C' programmer! Spot the 'C' programmer!
(Finally, it's not me for once... :-)
=Austin
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
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.
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
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
> 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
Ditto. Anybody know for sure?
> --- 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
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
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
>>># 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
is the "space-eating-underscore" gone ????
if ( $foo _{bar} # using whitespace to line up subscripts
or $piddle _{far} ) { # for visual reasons, but parens required
Which of the following (if any) is valid?
$foo.{bar}
$foo .{bar}
$foo. {bar}
> 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
I think the third should be illegal (until someone defines themselves
a postfix:. operator).
Larry
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?
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
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
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
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
> 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
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