On Fri, Dec 22, 2006 at 05:33:12PM +0100, Juerd wrote:
> Abigail skribis 2006-12-22 16:43 (+0100):
> > > > print sqrt(9) + 7; # Prints 10.
> > > > print sqrt (9) + 7; # Prints 4.
> > The space influences precedence.
>
> That's a result, not the cause.
>
> The cause is that the space tells Perl that () is NOT the function call
> parens anymore.
>
> The real source of this problem is that Perl wants to allow subroutine
> calls without parens:
>
> print "foo";
>
> which really means:
>
> print("foo");
>
> but can in Perl 5 also be written as:
>
> print ("foo");
>
> which is nice until you get used to:
>
> $foo = (3 + 4) * 5;
>
> being 35, and eventually try:
>
> print (3 + 4) * 5;
>
> and are bitten by this being the equivalent:
>
> print(3 + 4) * 5;
>
> which prints 7, and multiplies the return value of print() by 5,
> throwing the resulting 1*5==5 away.
Ah, come on. Perl has been around for 17 years. I've seen thousands of
postings of Usenet, mailing list, and even Perlmonks. I've yet to see
*any* posting were someone was getting confused that
'function (EXPR1) + EXPR2'
was parsed as '(function (EXPR1)) + EXPR2'.
>
> In Perl 6, however, parens that don't touch the function name
> intimately, are always considered grouping parens, so that:
>
> print (3 + 4) * 5;
>
> will print 35, instead of 7.
>
> Of course, languages that don't allow you to call functions without
> parens, don't have this problem:
>
> print((3 + 4) * 5);
>
> and can very easily allow whitespace before the opening paren:
>
> print ((3 + 4) * 5);
>
> It's nice for all those people coming from C and Java, who started to
> learn Perl.
Really? Do you really think that people coming from a language that
allows whitespace between the function name and the parenthesis find
it *nice* that in Perl the meaning of the statement silently changes
whether theres a space or not?
I think it's downright hostile.
>
> > Now, the other example I gave (%hash {code} vs %hash{code}) is a parsing
> > issue.
>
> They are both parsing issues, not precedence issues.
>
> In fact, it's exactly the same parsing issue: if you have whitespace,
> the thing following the whitespace is never parsed as a postfix
> operator.
>
> > Now, you might wonder what was gained by having this monster. It enables
> > you to leave of the parenthesis in an if statement.
>
> Both (equal) issues are to enable you to drop parens:
>
> print "foo"; instead of print("foo");
I guesss you don't know much perl5.
Really. The ability not to have parenthesis around function and subroutine
arguments isn't a new perl6 thingy.
Perl5 does do fine.
And the whitespace is optional in Perl5.
> if $foo == 5 { ... } instead of if ($foo == 5) { ... }
Woopy.
I'm dully impressed.
For want of not having to type parenthesis around a condition, we
get significant whitespace.
And people call it progress.
Buahahahhahahaahhahaa.
> It should be relatively easy to modify Perl 6's grammar to force parens
> on both, and allow whitespace in front of postfix ops. But it will bite
> in other places. Pick your hate :)
As as I said in a different post, not a sensible option.
> > Perl goes from a formfree language to a language with syntactically
> > whitespace for the benefit of making parenthesis around a conditional
> > optional.
>
> Perl has always had syntactic whitespace, just not in any strictly
> defined, language-wide consistent, way.
>
> > (So, what's 'grep {/foo/} @bar;' meaning in perl6?)
>
> Syntax error. grep takes two arguments, you need a comma in between:
>
> grep {/foo/}, @bar
So, all the trouble of having optional parenthesis around guards not
only gives use significant whitespace, but also robs us from the optional
comma?
And this is progress?
Abigail
pgpwQofhTjw5g.pgp
Description: PGP signature
