S04 - forbidden coding-style

[Markus Laire]

This quote from S04
<quote>
Outside of any kind of expression brackets, a final closing curly on a
line (not counting whitespace or comments) always reverts to the
precedence of semicolon whether or not you put a semicolon after it.
(In the absence of an explicit semicolon, the current statement may
continue on a subsequent line, but only with valid statement
continuators such as else. A modifier on a loop statement must
continue on the same line, however.)
</quote>

seems to say that a style like this can't be used by perl6-programmers:

loop
{
...
}
while $x;

I'd like to ask if it's necessary to make this programming-style
invalid for perl6? This style is used at least by "GNU Coding
Standards" (section 5.1) at
http://www.gnu.org/prep/standards/standards.html

I also like this style, as it lines up both the keywords and the curlies.

--
Markus Laire

[Smylers]

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.

Smylers

[Markus Laire]

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<while> belongs to the
preceding block.

(And that doesn't affect auto-indenting in vim)

--
Markus Laire

[Larry Wall]

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

[Jonathan Scott Duff]

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
du...@pobox.com

[Larry Wall]

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

[Ruud H.G. van Tol]

Larry Wall schreef:

> Maybe we should just make statement modifiers
> uppercase and burn out everyone's eye sockets. :)

Or maybe
{
}.
while $x ;

--
Groet, Ruud

[Trey Harris]

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

[Aaron Crane]

Larry Wall writes:
> Maybe we should just make statement modifiers uppercase and burn out
> everyone's eye sockets. :)

I like statement modifiers, and I want them to continue to exist in Perl 6.
But it seems to me that a lot of the most awkward decisions about Perl 6
syntax are awkward precisely because

EXPR
if EXPR;
BLOCK

and

EXPR;
if EXPR BLOCK

are so similar.

Bearing that in mind, would the eye-socket-burning

return $foo
IF $something;

really be so bad?

Alternatively, perhaps it's possible to find some other morphological or
syntactic device to distinguish statement_modifier:<if> from
statement_control:<if>, for both humans and the compiler. One option might
be to require an extra token (a postfix complementizer?) before a statement
modifier. Maybe something like this:

return $foo
--- if $something;

--
Aaron Crane

[Paul Hodges]

I know, shoot me -- but just so we've discussed it and put it to bed,
maybe :if or _if or fi?

<shudders>

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Kris Shannon]

On 7/22/06, Aaron Crane <pe...@aaroncrane.co.uk> wrote:
>
> Larry Wall writes:
> > Maybe we should just make statement modifiers uppercase and burn out
> > everyone's eye sockets. :)

...

Bearing that in mind, would the eye-socket-burning
>
> return $foo
> IF $something;
>
> really be so bad?

This has really started to grow on me.
I like this idea even if we don't change the rules for end of statement
after curlies.

[Thomas Wittek]

> Bearing that in mind, would the eye-socket-burning
>
> return $foo
> IF $something;
>
> really be so bad?

Operators/reserved words should be lowercase. Period. ;)
I think that this would heavily break consistency, annoying new users.

-Thomas

[Markus Laire]

There are already many uppercase reserved words in perl6:

Pseudo-packages from S02
MY, OUR, GLOBAL, OUTER, CALLER, CONTEXT, SUPER, COMPILING
Closure traits from S04
BEGIN, CHECK, INIT, END, FIRST, ENTER, LEAVE, KEEP,
UNDO, NEXT, LAST, PRE, POST, CATCH, CONTROL
From S10
AUTODEF, CANDO
Submethods from S12
BUILD, BUILDALL, CREATE, DESTROY, DESTROYALL
Pseudo-class from S12
WALK
I might've missed some.

So making statement modifiers uppercase would just be an another place
where perl6 uses uppercase reserved words.

--
Markus Laire

[Jerry Gay]

On 7/25/06, Thomas Wittek <ma...@gedankenkonstrukt.de> wrote:

perhaps this can be enabled with a pragma? i suggest C<use PERL;>
~jerry :)

[Thomas Wittek]

Markus Laire schrieb:

>> Operators/reserved words should be lowercase. Period. ;)
>> I think that this would heavily break consistency, annoying new users.
>
> There are already many uppercase reserved words in perl6:
>
> Pseudo-packages from S02
> MY, OUR, GLOBAL, OUTER, CALLER, CONTEXT, SUPER, COMPILING
> Closure traits from S04
> BEGIN, CHECK, INIT, END, FIRST, ENTER, LEAVE, KEEP,
> UNDO, NEXT, LAST, PRE, POST, CATCH, CONTROL
> From S10
> AUTODEF, CANDO
> Submethods from S12
> BUILD, BUILDALL, CREATE, DESTROY, DESTROYALL
> Pseudo-class from S12
> WALK
> I might've missed some.
>
> So making statement modifiers uppercase would just be an another place
> where perl6 uses uppercase reserved words.

Actually I don't know all of them but most seem to be (part of)
identifiers, not operators. Of course they are reserved words.

What I wanted to say is that it would annoy me, if almost all operators
and control-flow keywords are lowercase but a hand full of them has to
be written uppercase.

It would be especially annoying, if a keyword like "if" exists in both
lower and upper case. Besides the fact that is looks ugly and is a bit
harder to type, imho ;)

-Thomas

[Ruud H.G. van Tol]

Thomas Wittek schreef:

> Actually I don't know all of them but most seem to be (part of)
> identifiers, not operators. Of course they are reserved words.
>
> What I wanted to say is that it would annoy me, if almost all
> operators and control-flow keywords are lowercase but a hand full of
> them has to be written uppercase.
>
> It would be especially annoying, if a keyword like "if" exists in both
> lower and upper case. Besides the fact that is looks ugly and is a bit
> harder to type, imho ;)

returnif $something, $foo ;

return.if $something, $foo ;

$something and return $foo ;

--
Groet, Ruud

[po...@udo-guengerich.de]

Am Mittwoch, 26. Juli 2006 03:18 schrieb Ruud H.G. van Tol:
> Thomas Wittek schreef:

> >
> > What I wanted to say is that it would annoy me, if almost all
> > operators and control-flow keywords are lowercase but a hand full of
> > them has to be written uppercase.

Hi,

I suppose the above is a statement, true for quite a number of hackers.

> returnif $something, $foo ;
>
> return.if $something, $foo ;
>
> $something and return $foo ;

From all appended characters suggested so far, the comma seems to be the most
natural notation and that is big part of what Perl was to me in past:

Making programming as natural in terms of expressing language as possible.

So in my eyes,

do { $Worker.work() },
until $Day.letsCallItA();

return $Change, unless $Payment == $Price;

or

loop {

$Stuff.Do()
}
, while $TheresStuffToDo;

seems to be the most natural change in syntax, if
$WeReallyWantToAvoidTheBackslash ;)

I'm afraid though, it is also the most nasty one for parser-developers as you
cannot tell the difference between this and an expression very early...

???

Regards and many thanks for making Perl6!!!

--
Udo Güngerich
Grabenstr. 21
35396 Gießen

f: 0177 7495927
e: po...@udo-guengerich.de
w: http://www.udo-guengerich.de