On Thu, Jul 20, 2006 at 05:03:32PM +0100, Smylers wrote:
: Markus Laire writes:
:
: > S04 seems to say that a style like this can't be used by
: > perl6-programmers:
: >
: > loop
: > {
: > ...
: > }
: > while $x;
: >
: > I like this style, as it lines up both the keywords and the curlies.
:
: As of yesterday you can get very close to this by putting a space-eating
: backslash after the closing brace:
:
: loop
: {
: ...
: }\
: while $x;
:
: That still has the keywords and the braces aligned.
It's possible we can find a way to dwim that without the backslash,
but for now I'd say that check-at-the-end loops are so much rarer
than closing braces in general that it's a worthwhile hit even if we
end up requiring the backslash on that particular style. The problem with
any attempt to dwim it is that
loop
{
...
}
while $x {...}
looks like the same thing to the parser unless we delay deciding
about the "while" until the second {...}, or unless we make blank
lines significant (shudder). Alternately, a loop statement always
attempts to slurp a subsequent while or until (much like "if" slurps
an "else"), and then we rely on the fact that you will get a syntax
error as soon as you hit the second {...}, and we force any infinite
loop writer to use a semicolon to prevent the the syntax error:
loop
{
...
};
while $x {...}
The problem with relying on the syntax error is that every time you rely
on a syntax error to find one problem, two offsetting problems can
really ruin your day. Suppose they meant the above but said this:
loop
{
...
}
while $x{...}
So that particular dwim has a robustness strike against it, or at least
half a strike.
However, I'd guess that "infinite" loops will probably be more common
in practice than loop-while, since you tend to write exit-in-the-middle
loops using an infinite loop and "last if". We didn't even allow the
loop-while form in the initial design of Perl 6, and forced you to write
that as an "infinite" loop:
loop
{
...
last unless $x;
}
Another thing that needs to be said is that we probably should not
consider ourselves beholden to a coding style guide designed for
a different language with a different lexical structure. We've
certainly abandoned C and Unix culture in a number of other areas.
We're trying to make a language that will generalize into the future,
and that means we want to minimize special cases while making the
basic constucts more powerful. Trying to dwym on loop-while may fall
into the category of a special case that makes something else error
prone. One thing I've tried to guard in the lexical structure of
Perl 6 is that there are certain fixed sync points where we can know
that something is done with no more than one token of lookahead.
Semicolons have traditionally filled that role, and currently line-ending
curlies are in the same category. Likewise we try very hard never to
give a meaning to two terms in a row, because treating that as an
error catches lots of mistakes.
An if-else doesn't violate this because else is not something that can
occur as the beginning of another statement. Unfortunately, "while"
and "until" are in that category...
So another possibility is to introduce an else-ish word:
loop
{
...
}
mumble while $x;
but that that's even longer to type than the backslash "unspace", and
doesn't help with statement modifiers in general. So I'm inclined
to stick with the backslash for now. 'Course, you can always write
your own grammar too--which is something we officially try to encourage
but unofficially try to discourage. :)
Anyway, despite what I said about abandoning C culture, I like K&R-style
bracketing myself, so Perl is naturally a bit prejudiced in that direction.
I've only gone more to that style as my eyes have got worse, since it lets
me blow up the font and still keep a lot of lines on the page. I think
GNU style is wasteful of our natural resources. :)
All that being said, I do think the backslash is ugly, so it's
possible we might end up biasing the curly rule the other way if the
next token looks like a statement modifier. Still thinking about how
it will all work in practice, and in particular which failure modes
can give very good error messages like "Current line misinterpreted
as statement modifier, so previous line's } needs to be }; instead".
Or "Current line misinterpreted as statement, so previous line's }
needs to be }\ instead". And how often an ambiguous trailing {...}
might accidentally occur in a conditional expression...
It ain't easy. Maybe we should just make statement modifiers uppercase
and burn out everyone's eye sockets. :)
Larry
