Вы можете расширить ЛЮБОЙ термин для включения <&
, &>
и другого нетерминала (назовите его ANY_WITHIN_BLOCK скажем).
Тогда вы просто используете
ANY = "<&" | {ANY_WITHIN_BLOCK} | "&>"
codeblock = "<&" {ANY_WITHIN_BLOCK} "&>"
И тогда значение {ЛЮБОЙ} не изменится, если оно вам действительно понадобится позже.
Хорошо, я ничего не знал о CocoR и дал вам бесполезный ответ, так что давайте попробуем еще раз.
Как я начал говорить позже в комментариях, я чувствую, что реальная проблема заключается в том, что ваша грамматика может быть слишком свободной и недостаточно точно заданной.
Когда я писал CFG для одного языкаЯ пытался создать, и в итоге я использовал своего рода подход «встретиться посередине»: сначала я написал структуру верхнего уровня И непосредственные низкоуровневые комбинации токенов, а затем работал над тем, чтобы они соответствовалина среднем уровне (примерно на уровне условий и управления, я думаю).
Вы сказали, что этот язык немного похож на Java, поэтому позвольте мне показать вам первые строки, которые я напишу какпервый проект, чтобы описать его грамматикуr (в псевдокоде, извините.На самом деле это как YACC / Bison.И здесь я использую ваши скобки вместо Java):
/* High-level stuff */
program: classes
classes: main-class inner-classes
inner-classes: inner-classes inner-class
| /* empty */
main-class: class-modifier "class" identifier class-block
inner-class: "class" identifier class-block
class-block: "<&" class-decls "&>"
class-decls: field-decl
| method
method: method-signature method-block
method-block: "<&" statements "&>"
statements: statements statement
| /* empty */
class-modifier: "public"
| "private"
identifier: /* well, you know */
И в то же время, когда вы делаете все это, выясняйте ваши немедленные комбинации токенов, как, например, определение «числа» какfloat или int, а затем создание правил для добавления / вычитания / и т.д.их.
Я не знаю, каков ваш подход, но вы определенно хотите убедиться, что вы тщательно все задаете и используете новые правила, когда вам нужна конкретная структура.Не смешите себя при создании однозначных правил, но никогда не бойтесь создавать новое правило, если оно поможет вам лучше организовать свои мысли.