[prev] [thread] [next] [lurker] [Date index for 2006/12/22]
--vru7fAags9pVPvn5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Dec 22, 2006 at 05:52:36PM +0100, Juerd wrote:
> Abigail skribis 2006-12-22 17:34 (+0100):
> > > The parens for sqrt(9) are a post-circum-fix operator in Perl6.
> > A *what*?
>=20
> postcircumfix, one of the two binary operators.
>=20
> unary prefix ++foo
> unary postfix foo++
> unary circumfix {foo}
> binary infix foo + bar
> binary postcircumfix foo(bar)
>=20
> > Pointless argument. If it were that easy to tweak the grammar, the
> > whitespace would have been optional in the first place. You will NOT be
> > able to change the grammar easily (not because the syntax of changing
> > the grammar is necessarily difficult, but because the Perl6 grammar is
> > extremely complex, and changing one thing will have to mean a ton of
> > other things have to change as well. Perl6 ain't Forth nor Lisp).
>=20
> That's why after much debate and deliberation, the new whitespace rules
> are the way they are: it is considered by many wise people to be the
> only way to have a consistent solution.
You seem to be using 'consistent' as if that's a feature.
One of the reasons I was drawn to Perl was that it *didn't* think
consistency was one the most important rules. If I want consistency,
I know where to find Java and Python. The fact that Perl is inconsistant
means Perl is flexible and that it DWIM.
> > Besides, noone is interested in having a language were each coder
> > creates his/her own (incompatible) dialect.
>=20
> Erh. Heh. Funny that you mention this, as we're both Perl 5 coders, and
> both speak a very different, hardly compatible dialect!
No. We speak subsets of the same language, documented in the same set
of documents, and parsed by the same parser.=20
> > Perl5 had no problem coping with those rules (and it also uses ()
> > for clauses in if, while, etc, has optional () on the left hand side
> > of x, uses () around prototypes, etc), and it can all do that without
> > syntactically significant whitespace.=20
>=20
> That caused problems elsewhere:
>=20
> foo [ 5 ];
>=20
> would have to mean=20
>=20
> foo( [ 5 ] );
>=20
> according to many,
Not just "according to many" also according to perl:
$ perl -MO=3DDeparse -e 'sub foo; foo [5]'
foo([5]);
sub foo ;
-e syntax OK
> but if you apply your rule consistently, it'd be
>=20
> foo[5];
>=20
> which would take the 6th element of the array returned by foo().
Not only do I not follow your reasoning why applying "my" rule (whatever
my rule is) leads to the above meaning, I'm not in the least bit bothered
by this consistent thingy you keep mentioning.
I'm not consistent. Perl5 isn't. That's why Perl5 and I match. Perl5=20
generally does what I want without me having to think about it. *That's*
what I value in a language. Regardless whether it's doing what I want
in a consistent or a non-consistent way.
> For several reasons, the rules for all bracketing operators, and in
> fact, ALL \W postfix and postcircumfix operators, are now the same in
> Perl 6.
Goody. Another boring language. As if we hadn't enough "consistent"
languages already.
Abigail
--vru7fAags9pVPvn5
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFFjF75BOh7Ggo6rasRAvZ3AJ0elz6ROzZv8yOSo1YyQMkGmTgYRgCguVJ0
aQpfFlYoTjvxEOFNIyD/cLM=
=4d2q
-----END PGP SIGNATURE-----
--vru7fAags9pVPvn5--
There's stuff above here
Generated at 03:02 on 01 Jan 2007 by mariachi 0.52