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:

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?

--- Buddha Buck <bmb...@14850.com> wrote:

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

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 <brent...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

"If you're God, you know exactly what it would take to convince me. Do
that."
    --Marc Fleury on alt.atheism

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

--- Brent Dax <brent...@cpan.org> wrote:

Ditto. Anybody know for sure?

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

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:

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

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

 > 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
           boo();
       }

 > However, whitespace *is* allowed inside subscripts (as in Perl 5):
 >
 >   if $foo{   bar    }
 >          or $foo{ semprini } {
 >           boo();
 >   }
 >
 >
 > Damian
 >

Damian Conway:
# > 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}

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

"If you're God, you know exactly what it would take to convince me. Do
that."
    --Marc Fleury on alt.atheism

Brent Dax asked:

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

: 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

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?

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

"If you're God, you know exactly what it would take to convince me. Do
that."
    --Marc Fleury on alt.atheism

This is perfectly legal:

    $foo . bar;

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...)

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

--- Larry Wall <la...@wall.org> wrote:

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

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

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

--- Michael Lazzaro <mlazz...@cognitivity.com> wrote:

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

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

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

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.

I would hope not. But:

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

and

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

should work...

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

 >
 > 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