On 2/2/2010 4:01 AM, Kay Röpke wrote:
> Hi!
>
> I just hit this again for a project I'm working on, too. A chore.
>
> On Feb 2, 2010, at 4:31 AM, Gerald Rosenberg wrote:
>
>> On 2/1/2010 6:52 PM, Terence Parr wrote:
>>> Should I think about a (...)^[1] construct or something for v4?
>> Yes, just please don't further overload the caret and brackets with
>> completely different contextually dependent meaning! Also, its
>> ambiguous without the parens and if a space is put between the ")" and
>> "^" it might form a completely different valid construct.
>
> +1
>
>> Perl-like would be (...){n,m} -- if n and optional m must be ints, then
>> it is space tolerant and cannot be confused with an action (actually use
>> of the parens is conceptually consistent with use of parens for actions
>> - here defining a function applicable to the preceding element).
>
> I somewhat agree, but would also hate to overload the action meaning
> of '{…}'.
> Even though 'n,m' would be integers, what tells you that it is not a
> valid statement in the target language?
Just an integer; no semicolon; no assignment - so, doable
> I think it would be tricky to get right and could potentially be
> confusing.
True, though it is a common syntax across many languages.
>> Since you are making a clean break from everything v2, maybe (...)#1 --
>> makes the construct read very literally.
>
> What are the semantics of the # operator?
> Allow each alternative exactly once?
> Allow each alternative zero or one time?
Same as whatever Ter meant by (...)^[1] ;)
>
> How about making this thing an option, like greedy? For one thing,
> this use case isn't all that common and usually constrained to one or
> just a few rules, like type modifiers or optional blocks like in ANTLR.
FWIW, I have always found the embedded options block difficult to read
with certainty of scope -- the two examples differ only by the faint
presence of an additional colon. Fortunately, since Ter adjusted the
processing of .*, the need for an embedded options/greedy block seems to
be quite rare.
Best,
Gerald
_______________________________________________
antlr-dev mailing list
[email protected]
http://www.antlr.org/mailman/listinfo/antlr-dev
