Rafael Garcia-Suarez wrote:
Joseph F. Ryan wrote in perl.perl6.language :
I think the point of having C<if> 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<if> as special syntax, which is the real issue at hand.. I question whether treating C<if> 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]
