Re: explicit line termination with ;: why?
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 Cgiven with no block
defined? I.e. is
given $foo { when 1 {...} };
equivalent to
given $foo;
when 1 {...};
Re: explicit line termination with ;: why?
On 5/15/07, Dave Whipp [EMAIL PROTECTED] wrote:
A slightly tangental thought: is the behavior of Cgiven 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
Re: explicit line termination with ;: why?
On Tue, May 15, 2007 at 11:59:35AM -0700, Dave Whipp wrote:
: 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 Cgiven 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
Re: explicit line termination with ;: why?
On Tue, May 15, 2007 at 01:14:44PM -0600, Luke Palmer wrote:
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.
Maybe this is a case for one of Mr. Lang's custom semicolons with added
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.
signature.asc
Description: Digital signature
Re: explicit line termination with ;: why?
Larry Wall wrote:
Dave Whipp wrote:
: A slightly tangental thought: is the behavior of Cgiven 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
Re: explicit line termination with ;: why?
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?
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
__
[EMAIL PROTECTED] | http://www.shitov.ru
explicit line termination with ;: why?
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. 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 ;)
Re[2]: explicit line termination with ;: why?
JavaScript allows to omit semicolumn. Sorry, s/lumn/lon/. By the way, Perl also ignors semicolumn :-) -- Andrew Shitov __ [EMAIL PROTECTED] | http://www.shitov.ru
Re: explicit line termination with ;: why?
On Mon, May 14, 2007 at 07:05:01PM +0200, gabriele renzi wrote: : 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
Re: explicit line termination with ;: why?
On 5/14/07, Andrew Shitov [EMAIL PROTECTED] wrote: 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.)
Re[2]: explicit line termination with ;: why?
Aankhen wrote: 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. -- Andrew Shitov __ [EMAIL PROTECTED] | http://www.shitov.ru
Re: explicit line termination with ;: why?
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
Re: explicit line termination with ;: why?
Jonathan Lang wrote:
^[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
Re: explicit line termination with ;: why?
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. 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/ signature.asc Description: Digital signature
Re: explicit line termination with ;: why?
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. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: explicit line termination with ;: why?
On Tue, May 15, 2007 at 01:22:48AM +0200, Thomas Wittek wrote:
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.
--
Re: explicit line termination with ;: why?
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 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. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: explicit line termination with ;: why?
On 5/14/07, Daniel Hulme [EMAIL PROTECTED] wrote: 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
Re: explicit line termination with ;: why?
On Tue, May 15, 2007 at 02:02:06AM +0200, Thomas Wittek wrote: 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. --
