newline as statement terminator
Stéphane Payrard
statement terminator everywhere it can: that is when
a) the parser expects an operator
_and_ b) we are not in the middle of a parenthesised expression.
Accessorily, it would also help people to switch back and forth
between language that use newline as statement terminator and perl6:
they will not be burn anymore when forgetting a semicolon.
Semicolons are still allowed everywhere as statement terminator
because empty statements are.
So, In the common case, oneliner atomic statements, the proposed rule
means: you can drop the ending semicolon.
BTW: Atomic statement are statement composed of one expression only.
For composite multiline statements, see "About the b) rule" below.
Multiline atomic statements just have to be broken at the right
place to avoid to break them:
a +
b
is equivalent to
a + b
But
a
+ b
are two statements.
Note that in Perl5, semicolon is not always required as statement
terminator. At the end of a scope, being a closing brace, or the end
of a program, including an explicit eval or an implicit one (perldb
shell).
Note that, for Perl 6, Larry has already opened the path in his fourth apocalypse:
$x = do {
...
} + 1;
is different from
$x = do {
...
}
+ 1;
I just want to make a rule of what Larry made a special case.
About the b) rule.
------------------
The following code does not parse because of the newlines that are
interpreted as statement terminator.
for
1..10
{ ... }
But
for (
1.. 10
) {
}
is legit.
Smart parser may allow to avoid these otherwise spurious parentheses
--------------------------------------------------------------------
.. and make
for
1..10
{ ... }
a legit expression following the rule "what could have a meaning should".
The b) rule may not even be necessary with enough parsing state.
The parser could have the following exclusive states:
1) expecting an operator
2) expecting an operand (newline is statement terminator)
The expected operand is an expression that is part of an atomic statement
deemed as atomic.
3) expecting an operand (newline is ignored)
The expected operand is an expression that is directly part of
a composite statement. (as opposed as part of an atomic
statement part of a composite one).
What I mean by "deemed as atomic"?
When parsing a composite statement, we don't know from the start that
it is so. The following statement:
$a if $b
is deemed atomic until the parse deals with the 'if' token.
My proposition could then be expressed informally:
Newline is interpred as statement terminator when it makes sense.
It does not when :
A) in the middle of an expression when an operand is expected
B) within a parenthesised expression
C) and other cases that would also cause the parsing to return an error
Note: The b/ rule was an undeeded attempt to force C/ into B/.
--
stef
Luke Palmer
> From: =?iso-8859-1?Q?St=E9phane?= Payrard <st...@payrard.net>
>
> In the tradition of Perl concision, I would like newline to be a
> statement terminator everywhere it can: that is when
> a) the parser expects an operator
> _and_ b) we are not in the middle of a parenthesised expression.
Can you say "Ruby"?
No, I think a semicolon should still be required to seperate
statements.
> Accessorily, it would also help people to switch back and forth
> between language that use newline as statement terminator and perl6:
> they will not be burn anymore when forgetting a semicolon.
Of course, error detection as far as semicolons go is getting much
better. Parsers can determine (usually) exactly which line the
semicolon was left off of.
> Note that in Perl5, semicolon is not always required as statement
> terminator. At the end of a scope, being a closing brace, or the end
> of a program, including an explicit eval or an implicit one (perldb
> shell).
That's because, in Perl 5, semicolon is not a statement terminator.
It is a statement I<separator>. That is why you don't need it at the
end of various places, because you don't need to separate it from
anything.
> About the b) rule.
> ------------------
>
> The following code does not parse because of the newlines that are
> interpreted as statement terminator.
>
> for
> 1..10
> { ... }
>
> But
>
> for (
> 1.. 10
> ) {
> }
>
> is legit.
See, this is the main, unPerlish thing you're doing. You're enforcing
particular styles upon people, something Perl is proud of *not* doing.
Let's not forget the often occurence of:
$fh = open 'foobar'
or die "Can't open foobar: $!";
An implicit semicolon would cause it to croak there.
Also, s/or/$(any <<if unless for while when ...>>)/
It would be trivial with a grammar munge to implement this (heck, I
did it with a source filter in Perl 5). Surely CPAN6 (6PAN/CP6AN/??)
will come out with one of these right off the bat, so you could do:
use Grammar::ImplicitSemicolon;
Or something like that, and be done with it.
Luke
Stéphane Payrard
> Multiline atomic statements just have to be broken at the right
> place to avoid to break them:
Sorry about my English. Let me reformulate.
When folding an atomic statement, it becomes two statements or its
meaning is unchanged depending if an operand is expected or not at the
position of the folding.
>
> a +
> b
>
> is equivalent to
>
> a + b
>
> But
>
> a
> + b
>
> are two statements.
>
--
stef
Miko O'Sullivan
> In the tradition of Perl concision, I would like newline to be a
> statement terminator everywhere it can: that is when
> a) the parser expects an operator
> _and_ b) we are not in the middle of a parenthesised expression.
I don't mean to be abrupt here, especially seeing as how this list has
been so patient with some of my ideas but... PLEASE NO. The rules you
suggest for keeping track of when a semicolon is required sound more
confusing than the simple rule of "end of statement, put semicolon". I
like to break up my long statements in all sorts of arbitrary places, and
adding the worries of when a newline might be significant puts a knot in
my stomach just thinking about it (literally).
> Note that, for Perl 6, Larry has already opened the path in his fourth
> apocalypse:
NOTE TO ALLISON RANDAL: in your face-to-face meetings next week, please
make sure that "Larry Wall" isn't really Guido van Rossum with a fake
mustache.
-miko
Miko O'Sullivan
Programmer Analyst
Rescue Mission of Roanoke
Deborah Ariel Pickett
> did it with a source filter in Perl 5). Surely CPAN6 (6PAN/CP6AN/??)
> will come out with one of these right off the bat, so you could do:
>
> use Grammar::ImplicitSemicolon;
>
> Or something like that, and be done with it.
<silly>
The trick would be getting Perl to not require the semicolon at the end
of that use-line. :)
</silly>
<serious>
I agree entirely with what Luke just said in the email I'm replying to.
While it's possible to have Perl behave this way, I don't think Perl
programmers *in general* would want it. Heck, a lot of us aren't even
thrilled about the implicit-semicolon-at-brace-followed-by-newline rule
Larry introduced in A4.
</serious>
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep deb...@csse.monash.edu.au
"You gotta bat your eyes - like this." - _The Little Mermaid_
Stéphane Payrard
[snip]
>
> See, this is the main, unPerlish thing you're doing. You're enforcing
> particular styles upon people, something Perl is proud of *not* doing.
>
> Let's not forget the often occurence of:
>
> $fh = open 'foobar'
> or die "Can't open foobar: $!";
>
> An implicit semicolon would cause it to croak there
No, that case would not cause the inclusion of an implicit semicolon.
I certainly should have discussed such cases. But I have covered them
in the blanket statement "C) and other cases that would also cause the
parsing to return an error" because I am confident that the parser can
handle them.
What I said:
My proposition could then be expressed informally:
Newline is interpred as statement terminator when it makes sense.
It does not when :
A) in the middle of an expression when an operand is expected
B) within a parenthesised expression
C) and other cases that would also cause the parsing to return an error
>
> Also, s/or/$(any <<if unless for while when ...>>)/
>
> It would be trivial with a grammar munge to implement this (heck, I
> did it with a source filter in Perl 5). Surely CPAN6 (6PAN/CP6AN/??)
> will come out with one of these right off the bat, so you could do:
>
> use Grammar::ImplicitSemicolon;
>
> Or something like that, and be done with it.
I am certainly confident that in perl6, everyone will be able to bake
his own grammar. I am also confident that the grammar will be good
enough that we will not have to do it in the general case
>
> Luke
--
stef
Allison Randal
>
> NOTE TO ALLISON RANDAL: in your face-to-face meetings next week, please
> make sure that "Larry Wall" isn't really Guido van Rossum with a fake
> mustache.
Righto. No reptiles, only jewels and birds. And possibly the occasional
snark. ;)
Allison
Stéphane Payrard
> On Tue, 4 Feb 2003, [iso-8859-1] Stéphane Payrard wrote:
>
> > In the tradition of Perl concision, I would like newline to be a
> > statement terminator everywhere it can: that is when
> > a) the parser expects an operator
> > _and_ b) we are not in the middle of a parenthesised expression.
>
>
> I don't mean to be abrupt here, especially seeing as how this list has
> been so patient with some of my ideas but... PLEASE NO. The rules you
> suggest for keeping track of when a semicolon is required sound more
> confusing than the simple rule of "end of statement, put semicolon".
As Luke Palmer said, in perl6, semicolon is a statement separator not a
statement terminator. So there is no such simple rule in Perl but you
are free to imposit it on yourself. Perl allows it but it does not
requires it.
> I like to break up my long statements in all sorts of arbitrary places, and
> adding the worries of when a newline might be significant puts a knot in
> my stomach just thinking about it (literally).
>
>
I agree that be obliged to check the next line to see if the newline
is or is not a statement terminator is not the nicest thing.
On the other hand, if the programmer is correctly indenting the program
it should stand out that the next line is part of the courant statement.
print "-------" # must read the next line to
# figure out if new line is statement terminator or not
if $condition";
Here indentation is a mere clue but has no syntactic meaning.
[snip]
--
stef
Attriel
>> been so patient with some of my ideas but... PLEASE NO. The rules you
>> suggest for keeping track of when a semicolon is required sound more
>> confusing than the simple rule of "end of statement, put semicolon".
>
> As Luke Palmer said, in perl6, semicolon is a statement separator not a
> statement terminator. So there is no such simple rule in Perl but you
> are free to imposit it on yourself. Perl allows it but it does not
> requires it.
Er. What is the difference between a "statement seperator" and a
"statement terminator" for the majority case?
Seperator means I can leave off the last one in a {} b/c there's no
following statement ... But is there any other place I can "optionalize"
the ; by calling it a seperator vs a terminator?
I like having ;'s at the end of my bits, b/c then I know where a line
ends. When someone's pasting me bad (and I mean BAD) perl5 code, I like
having those ;'s there to tell me what ended where, since (The case i'm
thinking of offhand) was doing a print qq|| that printed out a BUNCH of
things and then ended with an if .. that ; was important b/c I kept
thinking hte if was part of the next line (it was on a seperate line,
making it even more fun)
Yes, this would make that program entirely not work, but I'm sure the new
version wouldn't be much prettier since there'd be no ;s at all
>> I like to break up my long statements in all sorts of arbitrary
>> places, and adding the worries of when a newline might be significant
>> puts a knot in my stomach just thinking about it (literally).
>
> I agree that be obliged to check the next line to see if the newline is
> or is not a statement terminator is not the nicest thing.
lookahead parsing is tolerable in a compiler, but in an interpreted/jit
environment, I'd HATE for my code to change meaning b/c i forgot a \n ...
esp if it's in generated code ... ewwww
> On the other hand, if the programmer is correctly indenting the program
> it should stand out that the next line is part of the courant statement.
>
>
> print "-------" # must read the next line to
> # figure out if new line is statement terminator or
> if $condition";
>
>
> Here indentation is a mere clue but has no syntactic meaning.
So, is the indentation required as a parser-hint (ewww, I hated mandatory
indents in fortran, and I can't see any good reason to bring them back;
stylistically I still think they're mandated, but not dictated by the
language) or is it just there to help people ?
And why is there a "; there? i presume the " is a typo, but since this
whole discussion is getting rid of the ;, I cna't see why it's there ...
Summary: ;'s good, indentation necessary but not parser-graphically
dicatated :o
--attriel
(parsergraphically?)
Deborah Ariel Pickett
> # figure out if new line is statement terminator or not
> if $condition";
Yes, let's expand that example, and assume the "semicolons optional
where obvious" proposal.
sub foo
{
print "abcde"
if $condition
{
print "fghij"
}
}
Is this
sub foo
{
# Conditionally print.
print "abcde" if $condition;
return sub {
# closure, see A4
print "fghij";
};
}
or is it
sub foo
{
print "abcde"; # Always print.
if $condition {
# Optionally print fghij right here.
print "fghij";
}
return; # No return value.
}
?
See the problem? Optional semicolons mean that something else has to
take up the syntactic slack, in this case extra keywords or indentation.
Personally, as a Perl programmer, I *like* semicolons. They are the
programming equivalent of the end-of-phrase markers you get in music to
tell your brain to take a breath.
Matt
>
> See the problem? Optional semicolons mean that something else has to
> take up the syntactic slack, in this case extra keywords or indentation.
>
> Personally, as a Perl programmer, I *like* semicolons. They are the
> programming equivalent of the end-of-phrase markers you get in music to
> tell your brain to take a breath.
Very good example. I'm new here, and new to the world of interpreters
(somewhat), but I do understand that the interpreter needs to know
where a statement ends very explicitly. A new-line would break this,
and present potential issues.. one of which Deborah showed.
Is that any real reason to add such a feature? Any advantage, or just
a personal preference? Honestly.. I think it would cause more harm
than good.. for perl nuts like myself, the interpreter itself, and
those coding the interpreter.
Nicholas Clark
> In the tradition of Perl concision, I would like newline to be a
> statement terminator everywhere it can: that is when
> a) the parser expects an operator
> _and_ b) we are not in the middle of a parenthesised expression.
>
> Accessorily, it would also help people to switch back and forth
> between language that use newline as statement terminator and perl6:
> they will not be burn anymore when forgetting a semicolon.
>
> Semicolons are still allowed everywhere as statement terminator
> because empty statements are.
>
> So, In the common case, oneliner atomic statements, the proposed rule
> means: you can drop the ending semicolon.
>
> BTW: Atomic statement are statement composed of one expression only.
> For composite multiline statements, see "About the b) rule" below.
>
> Multiline atomic statements just have to be broken at the right
> place to avoid to break them:
>
> a +
> b
>
> is equivalent to
>
> a + b
>
> But
>
> a
> + b
>
> are two statements.
And
$a = $something->{very}->[$complex] - $that('goes')->to(qw(the line end))
+ and_then('wrapped_like_this');
is two statements?
(and not even a "Useless use of a constant in a void context" warning)
Although I use this all the time, grovelling round the perl5 source, I could
only find this sort of idiom used in Match::BigInt's tests. And that was
like this:
plan tests => 669
+ 16; # own tests
There's nothing wrong with stealing, er "borrowing" the good bits of
reptiles though, is there?. I didn't think that perl was fussy about where
it gets its inspiration from. And they shouldn't complain, as imitation is
the sincerest form of flattery.
On Tue, Feb 04, 2003 at 02:24:48PM +1100, Deborah Ariel Pickett wrote:
> Personally, as a Perl programmer, I *like* semicolons. They are the
> programming equivalent of the end-of-phrase markers you get in music to
> tell your brain to take a breath.
Hmm. So if some saboteur erases all end-of-phrase markers from the musical
score you are reading, does that mean that after a while you turn blue and
then fall over? :-)
Nicholas Clark
Allison Randal
> There's nothing wrong with stealing, er "borrowing" the good bits of
> reptiles though, is there?. I didn't think that perl was fussy about where
> it gets its inspiration from.
It isn't and never will be. We're openly friendly to all languages. But
Perl is also quite different from most languages, so what works for them
may not work for us. It's a balance, like everything else in design.
Allison
Andy Wardley
> It's a balance, like everything else in design.
use Yin::Yang;
s/design/life/g;
A
John Williams
On Tue, 4 Feb 2003, Stéphane Payrard wrote:
> In the tradition of Perl concision, I would like newline to be a
> statement terminator everywhere it can: that is when
> a) the parser expects an operator
> _and_ b) we are not in the middle of a parenthesised expression.
I agree that this is bad because it will enforce style, which is something
we should _not_ do.
TCL has this rule, with the result that
if (foo)
{
do something
}
doesn't work, because "if (foo)" is an incomplete statement. So one is
forced into this style:
if (foo) {
do something
}
> Note that, for Perl 6, Larry has already opened the path in his fourth
> apocalypse:
>
> $x = do {
> ...
> } + 1;
>
>
> is different from
>
>
> $x = do {
> ...
> }
> + 1;
Well, I think the motivation was that
m/foo/ and do {
something;
}
print "done";
is such a terrible newbie-trap (it was for me, at least), that they had to
do something to fix it.
~ John Williams
Todd Olson
>In the tradition of Perl concision, I would like newline to be a
>statement terminator everywhere it can: that is when
> a) the parser expects an operator
> _and_ b) we are not in the middle of a parenthesised expression.
>
IMO this would be terrible!
It would mean I could no longer write
%months =
{ jan => '01'
, feb => '02'
, mar => '03'
, apr => '04'
, may => '05'
, jun => '06'
, jul => '07'
, aug => '08'
, sep => '09'
, oct => '10'
, nov => '11'
, dec => '12'
};
nor could I write
; if ( $planetary_tour )
{ $bill
= visit_mercury('bring water')
+ visit_venus('just look')
+ ( $sick_of_politics
|| $sick_of_over_population
|| $sick_of_polution
)
? visit_earth()
: 0
+ visit_mars()
}
# marketing insisted we say this
; print <<MARKETING
The cost of your trip was $bill
Travel with us again soon
MARKETING
# engineering details
; sub visit_mercury
{ my @accessories = @_
; encase_ship_in_radiation_shields
or abort_trip
; verify_solar_weather_is_good
or abort_trip
; flyby_quickly
; return 12000000
}
# etc ....
__END__
(ie view separators as line starters (rather than line enders))
Which is strangely addictive
... One of it's virtues is that it is easy to tell where statements start
... they always start with a ';' or similar punctuation
The more I use it the more I am addicted to it
Yes the style is strange
... but it is neat that one can explore a wide range of styles in Perl
... one reason I don't use python is because it does not give me this freedom.
Regards,
Todd Olson