Re: S04 - forbidden coding-style
On 7/20/06, Smylers <[EMAIL PROTECTED]> 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.
Yes. First I didn't like that additional slash, but now that I think
it more, it does give a nice visual clue that C belongs to the
preceding block.
(And that doesn't affect auto-indenting in vim)
--
Markus Laire
Re: S04 - forbidden coding-style
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
Re: S04 - forbidden coding-style
On Thu, Jul 20, 2006 at 10:18:57AM -0700, Larry Wall wrote:
> It ain't easy. Maybe we should just make statement modifiers uppercase
> and burn out everyone's eye sockets. :)
Or just give them some sort of syntactic marker ... I know!
loop {
...
}
:while $loopy;
eat :if $hungry;
go_postal :when $aggravation > 10;
.sleep :until .rested;
*Everybody* wants the colon! ;-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: S04 - forbidden coding-style
On Fri, Jul 21, 2006 at 12:07:52PM -0500, Jonathan Scott Duff wrote:
: Or just give them some sort of syntactic marker ... I know!
:
: loop {
: ...
: }
: :while $loopy;
:
: eat :if $hungry;
: go_postal :when $aggravation > 10;
: .sleep :until .rested;
:
: *Everybody* wants the colon! ;-)
Well, hmm, I actually thought of that one, but left it out since it's
ambiguous when a term is expected (unless we start turning pairs into
reserved words too).
Larry
[svn:perl6-synopsis] r10348 - doc/trunk/design/syn
Author: audreyt
Date: Fri Jul 21 11:40:37 2006
New Revision: 10348
Modified:
doc/trunk/design/syn/S02.pod
Log:
* S02: rodi++ pointed out a nit:
"say q<< <> >>"
should print " <> " not "<>".
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podFri Jul 21 11:40:37 2006
@@ -136,7 +136,7 @@
say #{{
This comment contains unmatched } and { { { { (ignored)
Plus a nested {{ ... }} pair(counted)
-}} q<< <> >> # says "<>"
+}} q<< <> >> # says " <> "
Note however that bare circumfix or postcircumfix C<<< <<...>> >>> is
not a user-selected bracket, but the ASCII variant of the C<< «...» >>
Re: S04 - forbidden coding-style
Larry Wall schreef:
> Maybe we should just make statement modifiers
> uppercase and burn out everyone's eye sockets. :)
Or maybe
{
}.
while $x ;
--
Groet, Ruud
Re: S04 - forbidden coding-style
In a message dated Fri, 21 Jul 2006, Ruud H.G. van Tol writes:
Larry Wall schreef:
Maybe we should just make statement modifiers
uppercase and burn out everyone's eye sockets. :)
Or maybe
{
}.
while $x ;
Actually, can't that be made to work already (already by the language
spec, not by the current compiler featureset) by
method Block::while ($block: Bool $true is deferred) {
$block() while $true
}
That would require parens around the boolean expression, though, but I'm
sure you can fix that with a parsing constraint.
Trey
[svn:perl6-synopsis] r10350 - doc/trunk/design/syn
Author: larry
Date: Fri Jul 21 12:52:51 2006
New Revision: 10350
Modified:
doc/trunk/design/syn/S04.pod
Log:
s/loop/repeat/ for test-after loops
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podFri Jul 21 12:52:51 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 19 Aug 2004
- Last Modified: 19 July 2006
+ Last Modified: 21 July 2006
Number: 4
- Version: 28
+ Version: 29
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -175,6 +175,14 @@
=head1 Loop statements
+Looping statement modifiers are the same as in Perl 5.
+Loop modifiers C, C, and C also work as in Perl 5.
+
+There is no longer a C block. Instead, use a C block
+within the body of the loop. See below.
+
+=head2 The C and C statements
+
The C and C statements work as in Perl 5, except that you
may leave out the parentheses around the conditional:
@@ -182,26 +190,59 @@
...
}
-Looping statement modifiers are the same as in Perl 5, except that
-to avoid confusion applying one to a C block is specifically
-disallowed. Instead of
+=head2 The C statement
+
+Unlike in Perl 5, applying a statement modifier to a C block is
+specifically disallowed:
+
do {
...
-} while $x;
+} while $x < 10; # ILLEGAL
-you should write
+Instead, you should write the more Pascal-like C loop:
-loop {
+repeat {
...
-} while $x;
+} while $x < 10;
-Loop modifiers C, C, and C work as in Perl 5.
+or equivalently:
-There is no longer a C block. Instead, use a C block
-within the loop. See below.
+repeat {
+ ...
+} until $x >= 10;
+
+Unlike Perl 5's C loop, this is a real loop block now, so
+C, C, and C work as expected. The loop conditional
+on a repeat block is required, so it will be recognized even if you
+put it on a line by its own:
-=head1 The general loop statement
+repeat
+{
+ ...
+}
+while $x < 10;
+
+However, that's likely to be visually confused with a following
+C loop at the best of times, so it's also allowed to put the
+loop conditional at the front, with the same meaning (the C
+keyword forces the conditional to be evaluated at the end of the loop,
+so it's still C's do-while semantics.) Therefore, even under GNU style
+rules, the previous example may be rewritten into a very clear:
+
+repeat while $x < 10
+ {
+ ...
+ }
+
+or equivalently:
+
+repeat until $x >= 10
+ {
+ ...
+ }
+
+=head2 The general loop statement
The C statement is the C-style C loop in disguise:
@@ -210,13 +251,16 @@
}
As in C, the parentheses are required if you supply the 3-part spec; however,
-as shown in the previous section, the 3-part loop spec may be entirely
-omitted to write an infinite loop. If you omit the 3-part loop spec
-you may add a C or C statement modifier at the end
-to make it a "repeat at least once" loop. Unlike C in Perl 5,
-it's a real loop block, so you may use loop modifiers.
+the 3-part loop spec may be entirely omitted to write an infinite loop.
+That is,
+
+loop {...}
+
+is equivalent to the Cish idiom:
+
+loop (;;) {...}
-=head1 The C statement
+=head2 The C statement
There is no C statement any more. It's always spelled C
in Perl 6, so it always takes a list as an argument:
@@ -293,12 +337,12 @@
compiler may have to retroactively change the binding of <$_> on the
left side. But it's what people expect of a pronoun like "it".)
-=head1 The do-once loop
+=head2 The do-once loop
In Perl 5, a bare block is deemed to be a do-once loop. In Perl 6,
the bare block is not a do-once. Instead C is the do-once
loop (which is another reason you can't put a C or C
-modifier on it).
+modifier on it; use C for that).
For any statement, prefixing with a C allows you to
return the value of that statement and use it in an expression:
Re: [svn:perl6-synopsis] r10350 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: > s/loop/repeat/ for test-after loops Yay! That makes things very clear, with different things looking nicely different. Smylers
