I'm implementing "MiniPerl6" in pugs which is the first step of
writing perl 6 parser in perl 6.  In module Pugs::Grammar::MiniPerl6,
 http://svn.openfoundry.org/pugs/misc/pX/Common/Pugs-Grammar-MiniPerl6,
I use another perl 6 grammar to describe it.  It works well several
days before when the parsing engine written in perl 5 did not
implemented :ratchet and :sigspace flags.

The grammar file can be found here:
http//svn.openfoundry.org/pugs/misc/pX/Common/Pugs-Grammar-MiniPerl6/lib/Pu gs/Grammar/MiniPerl6.grammar

The "token" part is fine, but the "rule" part is extremely ugly.  I can
not add additional spaces to format it.

I'd like to suggest two changes to make it easier to write rules:

  1. Spaces at beginning and end of rule blocks should be ignored
     since space before and after current rule are most likely be
     defined in rules using current one.
  1a. I'm not sure if it's "clear" to define as this, but the spaces
      around the rule-level alternative could also be ignored.  For
      instance, look at the rule FunctionAppExpr defined in
      MiniPerl6 grammar file.

        rule FunctionAppExpr
{<Variable>|<Constants>|<ArrayRef>|<FunctionName>[<?ws>?<'('><?ws>?<Paramet ers><')'>]?}

      I could not even put a new line in it.  In the file, since there
      are production rules, I put the brases on strange positions
      to format it better.

  2. I am not sure the default rule of <ws>, I couldn't found it in
     S05.  Currently the engine use :P5/\s+/ but I would like it to
     be :P/\s*/ when it's before or after non-words and remains
     the same (\s+) otherwise.

I do not subscribe this group but subscribe daily digest, so it's OK to
reply on the list.  Suggestions welcome!

Cheers,
Shu-Chun Weng

 (used to post on google group but found it does not deliver)

I'm implementing "MiniPerl6" in pugs which is the first step of
writing perl 6 parser in perl 6.  In module Pugs::Grammar::MiniPerl6,
 http://svn.openfoundry.org/pugs/misc/pX/Common/Pugs-Grammar-MiniPerl6,
I use another perl 6 grammar to describe it.  It works well several
days before when the parsing engine written in perl 5 did not
implemented :ratchet and :sigspace flags.

The grammar file can be found here:
http//svn.openfoundry.org/pugs/misc/pX/Common/Pugs-Grammar-MiniPerl6/lib/Pu gs/Grammar/MiniPerl6.grammar

The "token" part is fine, but the "rule" part is extremely ugly.  I can
not add additional spaces to format it.

I'd like to suggest two changes to make it easier to write rules:

  1. Spaces at beginning and end of rule blocks should be ignored
     since space before and after current rule are most likely be
     defined in rules using current one.
  1a. I'm not sure if it's "clear" to define as this, but the spaces
      around the rule-level alternative could also be ignored.  For
      instance, look at the rule FunctionAppExpr defined in
      MiniPerl6 grammar file.

        rule FunctionAppExpr
{<Variable>|<Constants>|<ArrayRef>|<FunctionName>[<?ws>?<'('><?ws>?<Paramet ers><')'>]?}

      I could not even put a new line in it.  In the file, since there
      are production rules, I put the brases on strange positions
      to format it better.

  2. I am not sure the default rule of <ws>, I couldn't found it in
     S05.  Currently the engine use :P5/\s+/ but I would like it to
     be :P/\s*/ when it's before or after non-words and remains
     the same (\s+) otherwise.

I do not subscribe this group but subscribe daily digest, so it's OK to
reply on the list.  Suggestions welcome!

Cheers,
Shu-Chun Weng

    token FunctionAppExpr {
        | <Variable>
        | <Constants>
        | <ArrayRef>
        | <FunctionName> [ <?ws> \( <?ws> <Parameters> \) ]?
    }

In fact, now that I've written the above I'm more inclined to say
it's not a good idea to ignore some whitespace in rule definitions
but not others.  Consider:

    rule FunctionAppExpr {
        | <Variable>
        | <Constants>
        | <ArrayRef>
        | <FunctionName>[ \( <Parameters> \) ]?
    }

Can we quickly determine where the <?ws> are being generated?
What if the [...] portion had an alternation in it?

(And, if we ignore leading/trailing whitespace in rule blocks, do
we also ignore leading/trailing whitespace in subpatterns?)

In a couple of grammars I've developed already (especially the
one used for pgc.pir), having whitespace at the beginning of rules
and around alternations become <?ws> is useful and important.
In these cases, ignoring such whitespace would mean adding explicit
<?ws> in the rule to get things to work.  At that point it feels like
waterbed theory -- by "improving" things for the FunctionAppExpr
rule above we're pushing the complexity somewhere else.

In general I'd say that in a production such as FunctionAppExpr
where there are just a few places that need <?ws>, then it's
better to use 'token' and explicitly indicate the allowed
whitespace.

(Side observation: in  ...|<FunctionName>[<?ws>?<'('><?ws>?<Parameters><')'>]?}
above, there's no whitespace between <Parameters> and the closing paren.
Why not?)

In P5 it'd probably be something like

    (?:(?<!\w)|(?!\w))\s*|\s+

or maybe better is

    (?:(?<!\w)|(?!\w)|\s)\s*

Pm

Thanks for the comments :)

I'll then rewrite most of my rules into tokens.  And about the
definition of <?ws>, the "engine" I mentioned is Pugs::Complier::Rule,
so that if what PGE does is considered the "correct" way, I will
change the behavior of P::C::Rule.  By the way, if someone can add
it to S05 would make me more comfortable.

Shu-Chun Weng

在 2006/6/3 下午 3:03 時，Shu-Chun Weng 寫到：

Cheers,
Audrey