explicit line termination with ";": why?
Gabriele Renzi
I don't want to argue about the design of perl6[1], I just wonder: why
the semicolon is still needed in the end of lines in perl6?
I can think of different reasons (history, readability, easier parsing
of multiline statements, force people to write one-line functions to
avoid typing them :) but I'm curious to know the real one.
Sorry if this is already been explained but my google-fu was not good
enough to find an answer.
[1] of course I actually do, but I know that I will be able to write my
own Grammar, to scratch my Wannabe Language Designer itches ;)
Andrew Shitov
> the semicolon is still needed in the end of lines in perl6?
JavaScript allows to omit semicolumn. In lecture at Yahoo's YUI
Theatre one of JS's gurus talked about how it is organized in
JavaScript parser.
If the line of code is not ended with ';' the parser tries first
to assume that the next line continues current one. If then syntax error
occurs, the parser _goes_back_ and make another asumption that previous
line was ended with semicolumn.
Probably there are much more than one way to implement ';'-less but it
either slows down the compiler or makes grammar more complex.
And in fact Perl 6 already allows not to type ';' at the end of
{block} ;-)
The following simple snippets work correctly with Pugs and perl5:
#### perl 6
sub debug ($value)
{
say $value
}
debug 'me'
##### perl 5
sub debug
{
print shift
}
debug 'me'
And finally, Perl is not an Assembler with one only instrucion per
line.
--
Andrew Shitov
______________________________________________________________________
an...@shitov.ru | http://www.shitov.ru
Andrew Shitov
Sorry, s/lumn/lon/.
By the way, Perl also ignors semicolumn :-)
Larry Wall
: Hi everyone,
:
: I don't want to argue about the design of perl6[1], I just wonder: why
: the semicolon is still needed in the end of lines in perl6?
:
: I can think of different reasons (history, readability, easier parsing
: of multiline statements, force people to write one-line functions to
: avoid typing them :) but I'm curious to know the real one.
The "real" one, eh?
These sorts of things are almost never for a single reason. Some of
it is my prejudice against dangling syntax, and perhaps prejudice
against anything resembling Fortran. Some of it is not wanting to
distinguish different kinds of whitespace any more than we already do.
Some of it is simplicity of parsing, both for the human reader as
well as for the computer. I think if I had to pick one reason,
though, it's that it allows the parser to understand the intent of
the writer much better and hence give more useful diagnostics when
something seems to be going wrong. Much more than other languages,
Perl depends on the prohibition against two terms in a row as a kind
of "self-clocking" mechanism to disambiguate programmer intent, and
not requiring a semicolon between the final term of one statement
and the first term of the next statement would tend to weaken that,
especially when the term starts with a prefix operator that could be
mistaken for an infix.
: Sorry if this is already been explained but my google-fu was not good
: enough to find an answer.
Honest questions deserve honest answers, even if they aren't simple answers.
Larry
Aankhen
> JavaScript allows to omit semicolumn.
Speaking of JavaScript, any experienced JavaScript programmer will
tell you that while semi-colons are in fact optional, you should
always treat them as mandatory, to avoid subtle errors creeping into
your code.
--
Aankhen
(We have no branches.)
Andrew Shitov
> Speaking of JavaScript, any experienced JavaScript programmer will
> tell you that while semi-colons are in fact optional, you should
> always treat them as mandatory, to avoid subtle errors creeping into
> your code.
We should also note that the idea of omitting ';' is not as simple as
<"\n" always means ";\n">. In mentioned JavaScript language one can
do this:
<script>
var
x
=
123
alert
(
x
)
</script>
and that will work!
";\n" can almost always be converted into "\n" but not vice versa.
Jonathan Lang
> ^[3]: If this were included in the core, you might even reverse things
> so that ';' is defined in terms of postfix:<.> or infix:{'<=='},
> depending on the context; in this case, postfix:<?> would be defined
> in terms of postfix:<.>, rather than postfix:<;>. In fact, the only
> thing keeping postfix:<.> from completely replacing postfix:<;> as a
> statement terminator and insisting that the latter always be used as a
> shortcut for feeds is the long tradition that the latter has in
> programming languages - much like perl 6's infix:<.> replaces perl 5's
> '->' because that's what everyone else uses.
Umm, never mind. I just realized that introducing a postfix:<.>
operator would complicate matters in unexpected ways by forcing
infix:<.> to require disambiguating whitespace, as per S02. This
would be Very Bad in several ways, e.g., an infixed dot is given as
the appropriate way to separate a postfix operator from the term in
front of it when whitespace is forbidden. Or the fact that 'foo.bar'
would no longer parse as expected. :sigh:
--
Jonathan "Dataweaver" Lang
Daniel Hulme
> 2. This brings up the possibility of custom-designed termination
> operators.
cf. Semi::Semicolons. I think that being flexible enough that people can
write packages like that is one of Perl < 6's greatest strengths.
Long may it continue. Of course, if Perl 6 is actually parsed using a
descendant of Larry's 'Perl 6 grammar as a Perl 6 grammar', the compiler
could easily (*cough*) provide hooks to edit the grammar at parse-time,
meaning you can write your own (lexically scoped) Semi::Semicolons, or
Semi::Line::Continuation::Markers, or even
Semi::I::Don't::Really::Want::Prefix::Operators::Available::As::Methods.
Then there need be no arguments about what it looks like, and everyone
will be happy, and all programmers will hold hands and stop having
holy wars. Maybe.
--
"Sometimes it's a Boat, and sometimes it's more of an Accident. It all
"Depends on what?" depends."
"On whether I'm on the top of it or underneath it."
-- A. A. Milne, 'Winnie-the-Pooh' http://surreal.istic.org/
Thomas Wittek
> If the line of code is not ended with ';' the parser tries first
Wouldn't that be unambigous?
foo = 23
bar = \
42
?
I think there would be no ambiguities and you only had to add additional
syntax for the rare cases instead of the common cases.
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: strea...@jabber.i-pobox.net
John Macdonald
> Andrew Shitov:
> > If the line of code is not ended with ';' the parser tries first
> > to assume [..]
>
> Wouldn't that be unambigous?
>
> foo = 23
> bar = \
> 42
>
> ?
>
> I think there would be no ambiguities and you only had to add additional
> syntax for the rare cases instead of the common cases.
Without explicit \ to join unterminated lines you get:
foo = 23
if x == 7
{ y = 5; z = 6 }
Is that:
foo = 23
if x == 7;
{ y = 5; z = 6 }
or:
foo = 23;
if x == 7
{ y = 5; z = 6 }
?
With explicit \ to join unterminated lines you just get more
ugliness than having semicolons. It's also, in many cases,
harder to edit - that's why a trailing comma in a list that
is surrounded by parens, or a trailing semicolon in a block
surrounded by braces, is easier to manage. The syntax of
the last element is the same as the rest so you can shuffle
the order around easily without having to add a separator to
the end of what used to be the final element and remove the
separator on what is now the final element.
Having punctuation where there is a stop is more natural than
having an explicit marker for "don't stop here, keep going".
--
Thomas Wittek
> It's also, in many cases,
> harder to edit - that's why a trailing comma in a list that
> is surrounded by parens, or a trailing semicolon in a block
> surrounded by braces, is easier to manage.
Now that the list is surrounded by parens makes clear that it ends with
the closing paren and not with a line break. So you could still use
commas (without backslashes) to separate the items over multiple lines.
See e.g. http://docs.python.org/ref/implicit-joining.html
> Having punctuation where there is a stop is more natural than
> having an explicit marker for "don't stop here, keep going".
That's the pro-semicolon reason that makes most sense in all comments
that I've read so far in this discussion.
But maybe that's just something where you have to get used to.
Jonathan Lang
> On Mon, May 14, 2007 at 02:29:11PM -0700, Jonathan Lang wrote:
> > 2. This brings up the possibility of custom-designed termination
> > operators.
>
> cf. Semi::Semicolons.
Close. I'm thinking "added functionality for semicolon alternatives"
rather than the "replace the semicolon" stunt that Semi::Semicolons
pulls. In particular, as long as there's no ambiguity between
prefix:<?> and postfix:<?>, I think that it would be quite useful for
postfix:<?> to act as a semicolon that additionally sets $_ equal to
the expression's value, allowing for a pseudo-Prolog style of syntax
(i.e., the code could include questions as well as declarations and
instructions).
--
Jonathan "Dataweaver" Lang
John Macdonald
> John Macdonald schrieb:
> > It's also, in many cases,
> > harder to edit - that's why a trailing comma in a list that
> > is surrounded by parens, or a trailing semicolon in a block
> > surrounded by braces, is easier to manage.
>
> Now that the list is surrounded by parens makes clear that it ends with
> the closing paren and not with a line break. So you could still use
> commas (without backslashes) to separate the items over multiple lines.
> See e.g. http://docs.python.org/ref/implicit-joining.html
I was actually talking about existing perl5 here. I write:
my %h = (
x => 100,
y => 75,
z => 99,
);
explicitly writing the "unrequired" comma on the last element
(z=>99). That way, if I add another element to the hash there's
no danger that I will forget to go back and add the comma to
the line above. Alternately, if I reorder the hash elements
(maybe sorting on the value instead of the key) I don't have
to check whether there is now a commaless line in the middle
of the reordered bunch.
--
Dave Whipp
> Close. I'm thinking "added functionality for semicolon alternatives"
> rather than the "replace the semicolon" stunt that Semi::Semicolons
> pulls. In particular, as long as there's no ambiguity between
> prefix:<?> and postfix:<?>, I think that it would be quite useful for
> postfix:<?> to act as a semicolon that additionally sets $_ equal to
> the expression's value, allowing for a pseudo-Prolog style of syntax
> (i.e., the code could include questions as well as declarations and
> instructions).
A slightly tangental thought: is the behavior of C<given> with no block
defined? I.e. is
given $foo { when 1 {...} };
equivalent to
given $foo;
when 1 {...};
Luke Palmer
> A slightly tangental thought: is the behavior of C<given> with no block
> defined? I.e. is
>
> given $foo { when 1 {...} };
>
> equivalent to
>
> given $foo;
> when 1 {...};
Doubtful.
However, I do think that it's useful to be able to treat the rest of
the current scope as a block (usually with a parameter), for certain
kinds of closure-heavy code. For example, instead of saying:
{
foo -> $x {
bar;
baz -> $y {
quux;
bizzle;
}
}
}
Writing that as, say:
{
foo -> $x;
bar;
baz -> $y;
quux;
bizzle;
}
Can really help readability in situations when the control flow wants
to look linear. That's not to say that the -> $x; syntax makes any
sense.
Luke
Larry Wall
: Jonathan Lang wrote:
:
: >Close. I'm thinking "added functionality for semicolon alternatives"
: >rather than the "replace the semicolon" stunt that Semi::Semicolons
: >pulls. In particular, as long as there's no ambiguity between
: >prefix:<?> and postfix:<?>, I think that it would be quite useful for
: >postfix:<?> to act as a semicolon that additionally sets $_ equal to
: >the expression's value, allowing for a pseudo-Prolog style of syntax
: >(i.e., the code could include questions as well as declarations and
: >instructions).
:
: A slightly tangental thought: is the behavior of C<given> with no block
: defined? I.e. is
It would be illegal syntax currently.
: given $foo { when 1 {...} };
:
: equivalent to
:
: given $foo;
: when 1 {...};
Both of these suggestions would seem to duplicate the existing construct:
$_ = $foo;
:-)
Of course, now someone will argue that unary:<=> should assign to $_ by
default, in which case we'd have to find a new interation operator...
Larry
Daniel Hulme
> However, I do think that it's useful to be able to treat the rest of
> the current scope as a block (usually with a parameter), for certain
> kinds of closure-heavy code.
functionality: you could have something that worked a bit like the
lambda-calculus ".". It would slurp up as much of the RHS as possible,
which would almost always[1] be until the end of the enclosing block,
and 'return' it (in a syntactic way) to whatever on the LHS wants a
block. So, like Mr. Palmer's example, you would get something like
sub do_stuff() {
my @foo = get_me_a_list;
for @foo :-
.subst(/bar/,'baz').say;
}
[1] By "almost always" I mean I can't think of a reason for it to
sometimes not be that, but one or more may exist. Anywhere you would
want it to stop before the end of the enclosing block you should
probably use curlies anyway to stop it being confusing.
I'm not sure whether I would use these magic brace-opening semicolons
even if they were in. It seems to be to be less readable, but maybe
that's just because I haven't seen a compelling enough example. In the
worst case they would lead to code that looks like the old-style TeX
idiom of "normal {\bf bold} normal", where you open braces around the
whole block and do a state-change-like thing inside rather than a
functional thing that takes the thing you want operated on as an
argument. That doesn't mean we shouldn't allow custom semicolons with
added functionality; just that maybe this is not the best use for them
after all.
--
Mary had a little sprout, From week to week, from month to month,
Its fleece was green as grass, She kept the sprout in tow,
She hitched it to a bit of string, And everywhere that Mary went,
The silly little ass. The sprout was sure to go.
Jonathan Lang
> Dave Whipp wrote:
> : A slightly tangental thought: is the behavior of C<given> with no block
> : defined? I.e. is
>
> It would be illegal syntax currently.
As I understand it, the proposal is to say that if the parser finds a
';' where it was expecting to find a control block, it treats the rest
of the current block as the expected control block - or something to
that effect. Eh... messy, and with no substantial gain.
> : given $foo { when 1 {...} };
> :
> : equivalent to
> :
> : given $foo;
> : when 1 {...};
>
> Both of these suggestions would seem to duplicate the existing construct:
>
> $_ = $foo;
>
> :-)
Agreed. But I think that postfix:<?> is rather clean:
$foo?
when 1 {...}
Two catches:
1. I could easily define postfix:<?> myself, save for one thing: what
would I put as the parameter for the 'is equiv' trait, so that it has
terminator precedence?
2. 'when' implicitly leaves its current block after successfully being
executed (as per 'last'), since it's designed primarily for use as one
of a set of mutually-exclusive options. I'm not sure how wise of a
decision that is, since it's easier to add a "last" to a block that
implicitly lacks one than it is to remove a "last" from a block that
implicitly includes one. Part of me would strongly prefer that "when
$x { ... }" be exactly equivalent to "if $_ ~~ $x { ... }", except for
the inability to append an else block to the former.
> Of course, now someone will argue that unary:<=> should assign to $_ by
> default, in which case we'd have to find a new iteration operator...
Horrors, no! '=$filehandle' works just fine for reading an iterator,
thank you...
I _might_ flirt with the idea of postfix:<=> being equivalent to a
filehandle's '.say' method (i.e., writing to an iterator) - or not.
Given the mandatory whitespace that a postfix operator imposes on an
equivalent infix operator, I'd strongly suggest that good practice for
Perl 6 would be to avoid defining both forms if at all reasonable; and
infix:<=> definitely has the edge here. (Rule of thumb: if you can
avoid doing something that will mandate or forbid whitespace, avoid
it.)
--
Jonathan "Dataweaver" Lang