Re: A proposal on if and else
Smylers wrote: Thom Boyer wrote: The primary advantage, to my mind, in using C, is that it eliminates the dangling-else ambiguity -- so splitting it in half removes almost ALL the value of even having an C keyword. Surely it's the compulsory braces, even with a single statement, which eliminates that problem? Almost. The compulsory-braces rule [a Perl 5 syntax decision I applaud] means that if test1 { statement_A; } elsif test2 { statement_B; } elsif test3 { statement_C; } is equivalent in meaning to if test1 { statement_A; } else { if test2 { statement_B; } else { if test3 { statement_C; } } } So if "elsif" becomes "else" followed by "if" in the scanner, the result is syntactically wrong _because_ the curly braces are required (a point that I missed in my earlier post): if test1 { statement_A; } else if test2 { # syntax error: missing open brace after 'else' statement_B; } else if test3 { # Oops, I did it again statement_C; } And let's not anybody say, "Well, 'elsif' gets converted to 'else' followed by '{' followed by 'if', then!", because that doesn't work. All the closing right curly braces would still be missing. So the compulsory curly braces make for a much more convincing argument against an "elsif" --> "else if" conversion in the scanner. Personally, I don't think anybody should be working this hard to make if/elsif/elsunless/else writeable as a subroutine. I don't think it should be put in that pigeonhole: it doesn't fit there very well. If we really need the comfort of knowing that if/else/etc. is writable in Perl 6, then we can all take comfort that it _is_ always possible (if not as convenient) using the much more general grammar-extension mechanism. =thom
Re: A proposal on if and else
Thom Boyer wrote: > The primary advantage, to my mind, in using C, is that it > eliminates the dangling-else ambiguity -- so splitting it in half > removes almost ALL the value of even having an C keyword. Surely it's the compulsory braces, even with a single statement, which eliminates that problem? These look ambiguous to me, with no C required: if test1 if test2 statement_A; else statement_B; if test1 if test2 statement_A; else statement_B; Where as putting the braces in there always disambiguates which C and C goes with: if test1 { if test2 { statement_A; } else { statement_B; } } if test1 { if test2 { statement_A; } } else { statement_B; } Smylers
RE: A proposal on if and else
Rafael Garcia-Suarez [mailto:[EMAIL PROTECTED]] wrote: > The tokeniser could send two tokens "else" and "if" whenever it > recognizes the keyword "elsif" -- so this isn't a problem. The primary advantage, to my mind, in using C, is that it eliminates the dangling-else ambiguity -- so splitting it in half removes almost ALL the value of even having an C keyword. =thom "More people worry themselves to death than bleed to death." -- _Tunnel_in_the_Sky_, Robert Heinlein
Re: A proposal on if and else
"Joseph F. Ryan" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Rafael Garcia-Suarez wrote: > > > >The tokeniser could send two tokens "else" and "if" whenever it > >recognizes the keyword "elsif" -- so this isn't a problem. > > > > I think the point of having C as a sub rather than as a separate > syntax is so the parser doesn't have to do anything special for > special keywords. The specialness could be generalized, so that its no longer a parser hack: #define elsif else if Dave.
Re: A proposal for separable verbs. (Was: Re: A proposal on if and else)
[EMAIL PROTECTED] (Austin Hastings) writes: > Let's support separable verbs. That (http://dev.perl.org/perl6/rfc/309.html) is a really good idea. -- Writing software is more fun than working.
RE: A proposal for separable verbs. (Was: Re: A proposal on if and else)
--- Brent Dax <[EMAIL PROTECTED]> wrote: > Austin Hastings: > # Let's support separable verbs. > # > # Here's how: > # > # # Note my arbitrary selection of _ as separation indicator. > # Feel free to replace this with something more appropriate: > # > # sub if($test, &block) > # _ elsif ($test, &block) is optional is floating is multi > # _ elsunless ($test, &block) is optional is floating is multi > # _ else (&block) is optional is fixed > > How do you name one of these suckers? > > %::{'if'} #Incomplete, and is there an %::{'elsif'}? > %::{'if_elsif_elsunless_else'}#Could conflict with other symbols > %::{'if _ elsif _ elsunless _ else'} #Depends on ordering > > Remember, this also has bearing on importing them from a module. > Full name, with full signature. if_elsif_elsunless_else($c,&b,$c,&b, $c, &b, &b); Maybe a special widget in the arglist to denote separability? This could be important for varargs multimethods. > # { > # while (!$args[0].test) shift; > > 1. Where did this $args come from? > 2. The while syntax is way wrong. > 3. How does else's test default to 1? > > # &args[0].block(); > > From this, it's obvious you forgot about sigil invariance. I can't even spell sigil invariance. And I'm nowhere close to sure that it would be valid to use "while" when in the middle of trying to define "if". I was "backfilling" the innards after writing the 'outards'. Just a competence fault on my part. > > # } > # > # Where: > # > # 1: I'm hacking real hard on the implementation. Better Ideas > Welcome. > # 2: space-underscore-space means "separable bit". Negotiable. BIW. > # 3: is optional/[dflt: required] means doesn't have to appear. > # 4: is floating/[dflt: fixed] means can appear in any order. > # 5: is multi/[dflt: single] means can appear more than once. > > 5 conflicts with multimethods. s/multi/repeatable/ or whatever. BIW. > > # I think this is one of those p6-ish generalizations: > # > # try/catch/finally > # do/while > # if/elsif/elsunless/else > # repeat/until > # (arguably: switch/case/default) > > Except that none of the other ones exist in Perl 6. :^) Because we have not heretofore had a cool syntax for separable verbs. Now we do. Now it can be possible to say "use pascal;" and get extra syntax overhead. Rejoice. :-/ > > try { > ... > CATCH { > ... > } > } > > loop { > ... > last unless cond; > } > > loop { > ... > last if cond; > } > > given(topic) { > when cond { > ... > } > > default { > > } > } > > IMHO, separable keywords are in general a bad design, so perhaps they > should be grammar-munge hard. We really don't need anything but else > (and possibly its friends) for our purposes, but we want them > everywhere, so I don't see why we shouldn't do it this way. Go us. One step closer to total world domination. =Austin
RE: A proposal for separable verbs. (Was: Re: A proposal on if and else)
Austin Hastings: # Let's support separable verbs. # # Here's how: # # # Note my arbitrary selection of _ as separation indicator. # Feel free to replace this with something more appropriate: # # sub if($test, &block) # _ elsif ($test, &block) is optional is floating is multi # _ elsunless ($test, &block) is optional is floating is multi # _ else (&block) is optional is fixed How do you name one of these suckers? %::{'if'} #Incomplete, and is there an %::{'elsif'}? %::{'if_elsif_elsunless_else'} #Could conflict with other symbols %::{'if _ elsif _ elsunless _ else'}#Depends on ordering Remember, this also has bearing on importing them from a module. # { # while (!$args[0].test) shift; 1. Where did this $args come from? 2. The while syntax is way wrong. 3. How does else's test default to 1? # &args[0].block(); >From this, it's obvious you forgot about sigil invariance. # } # # Where: # # 1: I'm hacking real hard on the implementation. Better Ideas Welcome. # 2: space-underscore-space means "separable bit". Negotiable. BIW. # 3: is optional/[dflt: required] means doesn't have to appear. # 4: is floating/[dflt: fixed] means can appear in any order. # 5: is multi/[dflt: single] means can appear more than once. 5 conflicts with multimethods. # I think this is one of those p6-ish generalizations: # # try/catch/finally # do/while # if/elsif/elsunless/else # repeat/until # (arguably: switch/case/default) Except that none of the other ones exist in Perl 6. :^) try { ... CATCH { ... } } loop { ... last unless cond; } loop { ... last if cond; } given(topic) { when cond { ... } default { } } IMHO, separable keywords are in general a bad design, so perhaps they should be grammar-munge hard. We really don't need anything but else (and possibly its friends) for our purposes, but we want them everywhere, so I don't see why we shouldn't do it this way. --Brent Dax <[EMAIL PROTECTED]> @roles=map {"Parrot $_"} qw(embedding regexen Configure) >How do you "test" this 'God' to "prove" it is who it says it is? "If you're God, you know exactly what it would take to convince me. Do that." --Marc Fleury on alt.atheism
A proposal for separable verbs. (Was: Re: A proposal on if and else)
--- "Joseph F. Ryan" <[EMAIL PROTECTED]> wrote: > If the final design stays the way it is now, there really won't be > a "lexer". Instead, a perl6 grammar parses the data, and builds up > a huge match-object as it, well, matches. This match object is then > munged into the optree. > With this in mind, I'll say it again: Let's support separable verbs. Here's how: # Note my arbitrary selection of _ as separation indicator. Feel free to replace this with something more appropriate: sub if($test, &block) _ elsif ($test, &block) is optional is floating is multi _ elsunless ($test, &block) is optional is floating is multi _ else (&block) is optional is fixed { while (!$args[0].test) shift; &args[0].block(); } Where: 1: I'm hacking real hard on the implementation. Better Ideas Welcome. 2: space-underscore-space means "separable bit". Negotiable. BIW. 3: is optional/[dflt: required] means doesn't have to appear. 4: is floating/[dflt: fixed] means can appear in any order. 5: is multi/[dflt: single] means can appear more than once. The last three (3, 4, 5) are really just match-hints to the rexer for "here's how to look for me": /if ((elsif | elsunless )*) (else )?/ Instead of, say, requiring all the elsif in front of all the elsunless, or whatever. I think this is one of those p6-ish generalizations: try/catch/finally do/while if/elsif/elsunless/else repeat/until (arguably: switch/case/default) are all just separable verbs: sub try (&block) _ catch ($e, &block) is optional is multi is fixed _ finally (&block) is optional is fixed; sub do (&block) _ while ($cond); # is single is fixed is required sub repeat (&block) _ until ($cond); # is single is fixed is required sub switch ($cond) _ case ($val, &block) is multi is required _ default (&block) is optional; (Note: This leaves switch statements looking like crap, so I'd really rather sugar them up. But the point is, you *could* to it that way.) switch ($x) case (10) { print 10; } case (11) { print 11; } default { print "Something else"; } =Austin
Re: A proposal on if and else
Joseph F. Ryan wrote in perl.perl6.language : > > If the final design stays the way it is now, there really won't be > a "lexer". Instead, a perl6 grammar parses the data, and builds up > a huge match-object as it, well, matches. This match object is then > munged into the optree. Oh, yes, I remember now. Thanks. > This means the grammar probably won't be anything resembling simple, > since it has to act as both a lexer and a parser at the same time. > However, that's not to say your hack couldn't work; in fact, it would > be easy to implement during the match-object-munging phase. Indeed. > However, it still treats C as special syntax, which is the real issue > at hand.. > > I question whether treating C as a function rather than as built-in > syntax will make the parser any simpler if "special block rules" keep > getting added to simply make it work. I'm in favor of keeping a few > "special blocks" if it makes things easier to implement/design in the > long run. Makes sense. Note that I'm not advocating "elsif", quite an horrible keyword, that I still mispell as "elseif" sometimes. But I like hacking on grammars ;-)
Re: A proposal on if and else
Rafael Garcia-Suarez wrote: Joseph F. Ryan wrote in perl.perl6.language : I think the point of having C as a sub rather than as a separate syntax is so the parser doesn't have to do anything special for special keywords. I think the goal was to simplify the compiler, but with the discussion of recent weeks, it certainly doesn't look like that happened. :) Simplify the compiler, yes; but (with my limited knowledge of Perl 6) I don't expect the tokenizer to be simple. And the hack I just proposed to the tokenizer is mostly stateless. If the final design stays the way it is now, there really won't be a "lexer". Instead, a perl6 grammar parses the data, and builds up a huge match-object as it, well, matches. This match object is then munged into the optree. This means the grammar probably won't be anything resembling simple, since it has to act as both a lexer and a parser at the same time. However, that's not to say your hack couldn't work; in fact, it would be easy to implement during the match-object-munging phase. However, it still treats C as special syntax, which is the real issue at hand.. I question whether treating C as a function rather than as built-in syntax will make the parser any simpler if "special block rules" keep getting added to simply make it work. I'm in favor of keeping a few "special blocks" if it makes things easier to implement/design in the long run. Joseph F. Ryan [EMAIL PROTECTED]
Re: A proposal on if and else
Joseph F. Ryan wrote in perl.perl6.language : > > I think the point of having C as a sub rather than as a separate > syntax is so the parser doesn't have to do anything special for > special keywords. > > I think the goal was to simplify the compiler, but with the > discussion of recent weeks, it certainly doesn't look like that > happened. :) Simplify the compiler, yes; but (with my limited knowledge of Perl 6) I don't expect the tokenizer to be simple. And the hack I just proposed to the tokenizer is mostly stateless. -- If strain on the lexer were a design criterion, I blew it long ago. -- Larry Wall
Re: A proposal on if and else
Rafael Garcia-Suarez wrote: Brent Dax wrote in perl.perl6.language : Yes, I know this means that we have 'else if' instead of 'elsif', but it's only two more characters and it makes the grammar cleaner. The tokeniser could send two tokens "else" and "if" whenever it recognizes the keyword "elsif" -- so this isn't a problem. I think the point of having C as a sub rather than as a separate syntax is so the parser doesn't have to do anything special for special keywords. I think the goal was to simplify the compiler, but with the discussion of recent weeks, it certainly doesn't look like that happened. :) Joseph F. Ryan [EMAIL PROTECTED]
Re: A proposal on if and else
Brent Dax wrote in perl.perl6.language : > Yes, I know this means that we have 'else if' instead of 'elsif', but > it's only two more characters and it makes the grammar cleaner. The tokeniser could send two tokens "else" and "if" whenever it recognizes the keyword "elsif" -- so this isn't a problem.
A proposal on if and else
Many people have pointed out the 'semicolon problem' with if and else--that is, if Perl intuits a semicolon after every codeblock that ends a blank line, you would have to cuddle all your elses: if $cond { ... } <-- Virtual semicolon here else { ... } My proposed solution to this is to make ALL codeblocks take an optional 'else', accessed by the $code.else attribute. Depending on what sort of builtin was being used, the else would mean different things: sub if($cond, &code) { $cond ?? code() :: &code.else(); } sub while(&cond, &code) { if(cond()) { #There's probably a way to do an # else without a goto, but... TOP: code(); return unless cond(); goto TOP; } else { &code.else(); } } sub for(@list is lazy, &code) { while(@list) { &code(@list.unshift); } else { &code.else(); } } The else on a subroutine declaration might be called if preconditions (PRE and POST) didn't match, or it might just be ignored. else would be able to take a single subroutine call instead of a block: if $cond { ... } else if $cond2 { ... } Yes, I know this means that we have 'else if' instead of 'elsif', but it's only two more characters and it makes the grammar cleaner. --Brent Dax <[EMAIL PROTECTED]> @roles=map {"Parrot $_"} qw(embedding regexen Configure) >How do you "test" this 'God' to "prove" it is who it says it is? "If you're God, you know exactly what it would take to convince me. Do that." --Marc Fleury on alt.atheism