Hello again Csounders!

I am a Csound newbie of two months, studying with Dr. Boulanger at Berklee. I am very light-footed in the world of programming, so the first month of being exposed to the syntax of the language was very intense and educational for me. However, in the span of the first month, I came up with three separate ideas about modifying the language that Dr. B liked. He has encouraged me to post all of them both to the Csound Mailing List and the cSounds.com forum in order to generate a discussion about their possible methods of implementation, since I myself am in no position to do such a thing.

Several days ago I posted the first of the three ideas, related to reforming the structure of the Advance (a) statement. It'd be awesome if you checked that out too if you haven't already. This is the second idea.

I have come across several situations in "stab-in-the-dark"-type, opcode-hunting Csound learning sessions where I found that I wanted to modify an optional argument that was located past several other optional arguments, yet not in some way dependent upon its predecessors. Most times, the opcode documentation reveals that all of the optional arguments have default values, yet one still needs to input these values in order to address the one you're trying to get to. I will pull up my example from the Csound Mailing List:

(excerpt from old email)

With regards to the .csd I've attached, one would enter some sort of convention (Dr. B suggested "z" or "da" or something of the sort instead of a number) in place of the preceding optional arguments, so that the new line of code would change from
krand randh 1000, 8, 0.5, 0, 200
to
krand randh 1000, 8, z, z, 200
Since 0.5 and 0 were not modified from their default values.

This is of course inapplicable when optional arguments are dependent on each other and contextually inclusive (such as iparm1 and iparm2 in a pluck), but you could see where this would start making sense when you start dealing with opcodes with slightly larger sets of arguments and optional arguments, such as granule or really any granular opcode, where maybe you'd want to modify "ipitch4" but not "iseed", "ipitch1," or "ipitch3."

(end of excerpt)

Richard Dobson replied to my Mailing List post and corrected that in fact Csound already does this with successive commas:

krand randh 1000, 8,,, 200

So, at this point, I guess it merely becomes a matter of what looks syntactically "cleaner," since this way is not in any way "broken." Dobson noted that it would make sense to also accept periods between the commas:

krand randh 1000, 8, ., ., 200

Since it would be consistent with the note list carry point format.

The advantage of this concept lies primarily in opcode experimentation fundamentally and then with Dobson's clarifications in merely organizing the look of the score a little better when you use "empty commas."

What do you folks think? Is it worth it?