[prev] [thread] [next] [lurker] [Date index for 2006/12/22]
--3sseE1tnmEs+TkKq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.
>=20
> That's a result, not the cause.
>=20
> The cause is that the space tells Perl that () is NOT the function call
> parens anymore.
>=20
> The real source of this problem is that Perl wants to allow subroutine
> calls without parens:
>=20
> print "foo";
>=20
> which really means:
>=20
> print("foo");
>=20
> but can in Perl 5 also be written as:
>=20
> print ("foo");
>=20
> which is nice until you get used to:
>=20
> $foo =3D (3 + 4) * 5;
>=20
> being 35, and eventually try:
>=20
> print (3 + 4) * 5;
>=20
> and are bitten by this being the equivalent:
>=20
> print(3 + 4) * 5;
>=20
> which prints 7, and multiplies the return value of print() by 5,
> throwing the resulting 1*5=3D=3D5 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'.
>=20
> In Perl 6, however, parens that don't touch the function name
> intimately, are always considered grouping parens, so that:
>=20
> print (3 + 4) * 5;
>=20
> will print 35, instead of 7.
>=20
> Of course, languages that don't allow you to call functions without
> parens, don't have this problem:
>=20
> print((3 + 4) * 5);
>=20
> and can very easily allow whitespace before the opening paren:
>=20
> print ((3 + 4) * 5);
>=20
> 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.
>=20
> > Now, the other example I gave (%hash {code} vs %hash{code}) is a parsing
> > issue.
>=20
> They are both parsing issues, not precedence issues.
>=20
> 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.
>=20
> > Now, you might wonder what was gained by having this monster. It enables
> > you to leave of the parenthesis in an if statement.=20
>=20
> Both (equal) issues are to enable you to drop parens:
>=20
> 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 =3D=3D 5 { ... } instead of if ($foo =3D=3D 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.=20
> > Perl goes from a formfree language to a language with syntactically
> > whitespace for the benefit of making parenthesis around a conditional
> > optional.
>=20
> Perl has always had syntactic whitespace, just not in any strictly
> defined, language-wide consistent, way.
>=20
> > (So, what's 'grep {/foo/} @bar;' meaning in perl6?)
>=20
> Syntax error. grep takes two arguments, you need a comma in between:
> =20
> 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
--3sseE1tnmEs+TkKq
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFFjAvSBOh7Ggo6rasRAkYFAKCOqX+sRG8kjKTlYpBgVFOwrJAb2gCeKErO
14KSsx1RlIK82Wm4GjUbuCk=
=Vere
-----END PGP SIGNATURE-----
--3sseE1tnmEs+TkKq--
There's stuff above here
Generated at 03:02 on 01 Jan 2007 by mariachi 0.52