2

In my DSL variables are dynamic, they are created the first time a value is assigned to them. So this is a valid code:

a = 0
b = 2 // new variable created
a = 3 // existing variable reassigned

My naive approach is to have rules like this

Identifier:
  ID; // ID from Terminals

Assignable:
  {Assignable} ref=[Identifier|ID] |
  {Assignable} newVar=Identifier;

It doesn't work, complaining "The following alternatives can never be matched: 2". It's understandable, because the generated Antlr debug grammar contains a rule:

ruleAssignable: ruleIdentifier | ruleIdentifier;

(The trick of [Identifier|ID] comes from a response to a question on cross-referencing. I just copied it without fully understanding :) I also tried to grok how it's solved in the Xbase grammar:

{XAssignment} /* (declaringType=[types::JvmDeclaredType] '::')? */ feature=[types::JvmIdentifiableElement|ValidID] OpSingleAssign value=XAssignment

It seems to use only cross-referencing, and I can't see how new variable declaration is handled.

Adam Schmideg
  • 10,590
  • 10
  • 53
  • 83

1 Answers1

1

It's not a particularly good idea to use the same syntax for a variable declaration and an assignment expression. If possible I'd introduced a keyword or a special operator for the declaration.

In case you can't or don't want to do that, the hard way would be to decide on either a cross-reference or a simple identifier.

If you go with the first, you'll have to disable error messages for unresolved references. If you choose the latter, you'll have to pimp content assist and hyperlinking manually.

Sven Efftinge
  • 3,065
  • 17
  • 17
  • It's the existing grammar of coffeescript, so I can't change it. I get the impression from your answer that it's easier to go with cross-reference, and disable error messages in the context of assignment. – Adam Schmideg Dec 08 '11 at 17:10