Re: explicit line termination with ";": why?
Larry Wall wrote: Dave Whipp wrote: : A slightly tangental thought: is the behavior of C 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?
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?
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 C 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 5/15/07, Dave Whipp <[EMAIL PROTECTED]> wrote: A slightly tangental thought: is the behavior of C 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?
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 with no block defined? I.e. is given $foo { when 1 {...} }; equivalent to given $foo; when 1 {...};
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. --
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?
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 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?
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 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?
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?
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: and infix:, 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[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: var x = 123 alert ( x ) 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?
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: 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[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
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: 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