Re: S04 - forbidden coding-style
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: [EMAIL PROTECTED]
w: http://www.udo-guengerich.de
Re: S04 - forbidden coding-style
On 7/22/06, Aaron Crane [EMAIL PROTECTED] 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.
Re: S04 - forbidden coding-style
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
Re: S04 - forbidden coding-style
On 7/25/06, Thomas Wittek [EMAIL PROTECTED] wrote: 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. 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
Re: S04 - forbidden coding-style
On 7/25/06, Thomas Wittek [EMAIL PROTECTED] wrote: 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. perhaps this can be enabled with a pragma? i suggest Cuse PERL; ~jerry :)
Re: S04 - forbidden coding-style
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
Re: S04 - forbidden coding-style
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
Re: S04 - forbidden coding-style
I know, shoot me -- but just so we've discussed it and put it to bed, maybe :if or _if or fi? shudders --- Aaron Crane [EMAIL PROTECTED] wrote: 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: S04 - forbidden coding-style
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
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 Cwhile 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 KR-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
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
S04 - forbidden coding-style
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
Re: S04 - forbidden coding-style
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
