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
eliminat
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 prob
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
"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
[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.
--- 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
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
# _ elsun
--- "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
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 re
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 o
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
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 keywor
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 probl
13 matches
Mail list logo
