gabriele renzi wrote:
Hi everyone,
I don't want to argue about the design of perl6, I just wonder: why
the semicolon is still needed in the end of lines in perl6?
It isn't - sometimes. S03 identifies a number of ways that an
expression can be terminated: the semicolon (';'), a block-final
('}'), a control block (' { ... }'), a statement modifier
('if'|'unless'|'while'|'until'|'for'|'given'|'when')^, or a feed
operator ('<<==', '<==', '==>', '==>>').
^ FWIW, S03 needs updating, since it doesn't list 'given' or 'when'
among the statement modifiers in the block termination section.
A couple of thoughts:
1. There's a subtlety here: termination of an expression is not always
the same as termination of a statement. In particular, ';' is pretty
much equivalent to the '<==' feed operator when used in a bracketing
construct [1]^, and feed operators in general don't appear to force
statement termination the way that control blocks, statement
modifiers, and block-finals do. Of course, this distinction may be me
misunderstanding how expression termination works.
2. This brings up the possibility of custom-designed termination
operators. Question: which kinds of operators can have this
precedence? That is, prefix, postfix, infix, circumfix, or
postcircumfix? It appears to me that our current list of termination
operators includes analogs of most of these: postfix:<;>,
infix:{'<=='}, circumfix:<{ }>, and postcircumfix:«\s{ }» [2]^.
Meanwhile, how much clarity does the parser have between postfix
and infix? That is, if I defined both postfix:<foo> and infix:<foo>,
would the parser be able to reliably distinguish between them? This
matters to the current topic because ';' could be thought of as
'postfix-like' when used to terminate a statement, and 'infix-like'
when being used to construct feeds; if clarity between postfix and
infix exists, you might be able to do away with the "bracketed
context" clause - though it might not be wise to do so, even if you
could.)
I'm thinking about this in terms of the possibility of adding more
punctuation to the syntax: consider something akin to a postfix:<?>
operator that behaves exactly like postfix:<;>, except that it
automatically topicalizes the expression's value. Or a postfix:<.>
that always behaves the way that postfix:<;> does at statement level
[3]^. Borrowing from Spanish, circumfix:<¿ ?> might be to
circumfix:<{ }> as postfix:<?> would be to postfix:<;>. And so on.
As long as we maintain clarity between the grammatical categories,
such "punctuation operators" shouldn't present any difficulty; e.g.,
postfix:<?> will not clobber prefix:<?> or vice versa, even if the
former has terminator precedence and the latter has symbolic unary
precedence.
Or is this the sort of thing that you'd rather consign to explicit
hacks of the parser?
^[1]: see S09.
^[2]: Admittedly, this last one cheats a bit by putting whitespace
into the delimiter. But the principle is the same.
^[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.
--
Jonathan "Dataweaver" Lang
