Parser problems

[jpcima]

Some current parser problems, checked against ARIA and Cakewalk.

---

• [x] recursive dollar variable expansions (#230) validity: ARIA, Cakewalk

If the variable expands to another string with dollar, it should be expanded again. Example:

#define $A 1
#define $B $A
$B

⇒ 1

---

• [x] stop reading the #define value at the first space (#230) validity: ARIA

#define $A foo bar

In ARIA, the value of A is foo. Anything which follows is parsed like SFZ syntax. In Cakewalk, the value of A is foo bar.

This means also in ARIA you can write such things as: #define $A foo #define $B bar

---

• [x] don't left-trim the #define value (probable bug, not implemented unless necessary) validity: ARIA

Example:

#define $A   foo

The value of A will be " foo", with the spaces included. In Cakewalk, the value is left-trimmed.

---

• [ ] expand the dollar variables across several tokens of the grammar validity: ARIA, Cakewalk

Example:

#define $MyOpcodes sample=*sine
//This form Cakewalk-only:  #define $MyOpcodes pitch_keycenter=69 sample=*sine
<region> $MyOpcodes

In Cakewalk, the example is treated as two opcodes in a region. In ARIA, this is only the first opcode in the region, because is stopped reading the value at the first space. (see other case above)

[jpcima]

Since there's apparently out there some ARIA files which depend on Example: #define $A 1 #define $B 2

230 implements it same as ARIA, which is to stop reading the value as soon as whitespace is encountered. It contradicts Cakewalk behavior which extracts all the line.

We should decide a middle-ground solution for compatibility.

One idea is to examine the text under cursor when meeting a space. (eg. just after "1" in the example above) If the lookahead is '#', '<', or some "opcode=[...]", we may stop reading the value there, otherwise continue.

[paulfd]

So the 4th item

expand the dollar variables across several tokens of the grammar (validity: ARIA, Cakewalk)

is also handled by #230?

[jpcima]

No this one is significantly harder in the state of things. Hopefully, there aren't many files out there using this crazy form.

When tokens are expanded as a result of $-expansion, there isn't an adequate SourceRance to assign to them. This would have to be handled in a simliar way to how libclang does. Essentially it's a distinction between a file location and a semantic location, where the latter points to the content of a macro expansion.

Then after having this, the next problem is to reexamine the way how to process the character stack. In case of ungetting chars, it has to track whether the character source is from a $-expansion or from file, and keep the state accordingly.

[jpcima]

• [ ] more fun with ARIA and definitions #define $give <region> #define $me$ sample=* $give$me$sine

[paulfd]

Meh. I was hopeful about this one thinking "Ho, having #define $MyOpcodes opcode1=value1 opcode2=value2 ... would be a compatible way to implement composition rather than hierarchies in SFZ file" but it doesn't work in ARIA then...