Permitted locations of a version condition

[Phil Deets]

On Thu, 29 Oct 2009 23:26:39 -0500, Ellery Newcomer  
<ellery-newcomer at utulsa.edu> wrote:

> Phil Deets wrote:
>>
>> I put the comma inside the version block because then there wouldn't be
>> duplicate commas if the version was removed. If the version number was 6
>> in the above example, it would evaluate to "A, B, C, D, E," with my way,
>> but
>>
>> enum Tag
>> {
>>    A, B, C,
>>    version (5) {
>>       D, E
>>    },
>>    version (7) {
>>       F, G
>>    },
>>    // ...
>> }
>>
>> would evaluate to "A, B, C, D, E, ," which has two commas in a row.
>> However, you could keep version blocks separated with commas if you
>> specialized the enum grammar specifically for version blocks, which
>> might be the right way to go.
>
> It really doesn't matter. By the time you get around to evaluating the
> version condition, you'll have thrown away all those commas anyways. All
> that matters is that you can clearly distinguish the members. However,
> it will be simpler to implement (and express in ebnf) if you separate
> versions/members with commas. Like
>
> enumBody -> { enumMembers }
> enumMembers -> enumMember , enumMembers
> enumMembers -> enumMember ,
> enumMembers -> enumMember
>
> enumMember -> Identifier
> enumMember -> Identifier = AsgExp
> enumMember -> ccCondition enumBody
>
>

Good point. That makes sense when I think of it that way. I was thinking  
in a preprocessor mindset where the text had to make sense if the version  
just disappeared like the text does with the C preprocessor.