In Parser.hs:589, we have the code:

parseParamList parse =    parseParenParamList parse
                      <|> parseNoParenParamList parse

parseParenParamList parse = do
    [inv, norm] <- maybeParens $ parseNoParenParamList parse
    block <- option [] ruleAdverb
    -- XXX we just append the adverbial block onto the end of the arg list
    -- it really goes into the *& slot if there is one. -lp
    processFormals [inv, norm ++ block]

But this allows the syntax '$x.foo $y', that is, an argument to a method
call without parentheses.  This isn't a big deal, and could even be
construed as a feature, if it weren't for:

    for %hash.keys { ... }

Which is misparsed.

Taking out maybeParens and putting 'option [[],[]] $ parens' in its
place makes that part work, but it breaks our regular 'say "foo"'
paren-less syntax.  I would think that the parseParamList rule above
would fix that.  No matter where I put 'try', it never seems to want to
go to parseNoParenParamList.

Luke

: But this allows the syntax '$x.foo $y', that is, an argument to a method
: call without parentheses.  This isn't a big deal, and could even be
: construed as a feature, if it weren't for:
:
:     for %hash.keys { ... }
:
: Which is misparsed.

Which is why recent versions of A12/S12 outlaw arguments to methods
without parens.  Method calls cannot be parsed with the same rules as
functions and list operators, unfortunately.  The original A12 tried
to make that work, at the expense of arcane lookahead rules, but it
just got too bizarre.  Those braces above *have* to know that they're
where an operator is expected.  Since we can omit method parens on
argumentless method calls and on method calls that have only adverbs,
requiring parens only on methods with extra arguments is a fair price
to pay for dropping parens off of the conditional expression, I think.

[A reminder that implementation followups can certainly go here, but
philosophical followups should probably be rerouted to p6l.  A certain
amount of leakage is necessary, of course, and I don't mind answering
short design clarifications here, as long as they don't clutter the
list with the sorts of idle speculations that are more typical on p6l.]

Larry