Smylers wrote:
Thom Boyer wrote:
The primary advantage, to my mind, in using Celsif, is that it
eliminates the dangling-else ambiguity -- so splitting it in half
removes almost ALL the value of even having an Celsif keyword.
Surely it's the compulsory braces, even with a single statement,
b 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:
proposal rating='NOOOooo'
#define elsif else if
/idea
Dave.
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 Celsif, is that it eliminates
the dangling-else ambiguity -- so splitting it in
Thom Boyer wrote:
The primary advantage, to my mind, in using Celsif, is that it
eliminates the dangling-else ambiguity -- so splitting it in half
removes almost ALL the value of even having an Celsif keyword.
Surely it's the compulsory braces, even with a single statement, which
eliminates
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
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.
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
Rafael Garcia-Suarez wrote:
Joseph F. Ryan wrote in perl.perl6.language :
I think the point of having Cif 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
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
--- 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,
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
# _
--- 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,
[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.
13 matches
Mail list logo
