On Sat, Oct 31, 2009 at 1:39 PM, Abigail <abigail@abigail.be> wrote: > On Fri, Oct 30, 2009 at 06:59:23PM -0400, George Greer wrote: >> On Fri, 30 Oct 2009, Eric Brine wrote: >>> His post wasn't clear, but given the result from the first two tests, it >>> looks like he's working on making them optional. >> Yes, exactly. > The most important reason I've no interest in Perl6, up to the point I'm > more likely to become a Java programmer than to ever write a Perl6 program > is that Larry forbid the usage of white space between '$hash' (or should I > say '%hash'?) and its subscript. A curly brace preceeded by whitespace is > always a block in Perl6. > > He did this to be able to leave the parens of an if. What if GG's patch makes container lookup syntax white-space sensitive, but only between C<if> and the first opening curly brace following whitespace? if (EXPR) BLOCK # what we have if EXPR BLOCK # what is desired to be allowed could the expression parsing rules change following an if or unless or while or until but nowhere else (except the other boolean situation I left out) so that white space is significant before an opening curly-brace at the same level as the C<if> as it signifies the start of the BLOCK, and without space container lookup is indicated. How pervasive would this new boolean context be? "Conditional" context it could be called, as it appears in conditional procedural flow-of-control syntax, but not in functional/operatoral flow-of-control syntax such as C<and> or C<or>. Or even within the parentheses of a normal if statement. It would only appear where the syntax currently demands a parenthesized boolean. The perl-6-language mailing list once attempted to have a guideline of only suggesting new syntax that would give a syntax error in the perl 5 of 2000; this suggestion -- "Make the parentheses around the conditions of flow-of-control syntax optional" -- would qualify.Thread Previous | Thread Next