Elias asked some questions about selection variables:
- Is there a way to get the current index of a selection var?
- Is there a way to get an item by index (i.e. random access)?
Currently, no.
In their present incarnation, selection variables just do bookkeeping for randomization (similar to what Trial/Block/List structures are able to do for their contents, but without being hierarchically organized the way trials and blocks are). In fact, the original hope was that people would use the trial/block/list randomization capabilities instead, but there were too many cases where it was convenient to use something “free floating” instead, and everyone seems to prefer to work this way.
They don’t currently behave like arrays, though we could certainly add that functionality. More generally, a common wish-list item is to expose array and dictionary-style values in variables in general (internally these data types exist, but the user can’t get at them). To do this, we’d probably want to extend the ExpressionParser classes (e.g. to add parsing infrastructure for a bracket operator). The STX expression parser that we’ve borrowed uses boost.spirit, which is quite complex, but it would’t be hard at all to follow the lead of the function call expression (i.e. just replace “(” and “)” with “[” and “]”). That way one could create an expression like “my_selection_variable[0]” or “my_selection_variable[index]” that would access the first or variable element of the selection variable’s array of options. One could also imagine adding an “attribute” operator (e.g. “my_selection_variable.current_index”).
I think that the “first-order” version of this kind of addition would be relatively straightforward, but it definitely falls under the category of "0.4.5-at-the-earliest. " It would bring us one step closer to recapitulating an entire programming language inside MW, which raises the question of whether it wouldn’t be better to allow inline code blocks from a well-established existing language (e.g. Python or JS, via bindings) instead. In any case, we’d also have to come up with a way to sensibly handle exceptions (e.g. out of range). These are issues that we’ve been moving towards addressing for a while now, but priorities have so far always been on getting everyone’s experiments running over nailing the semantics and structure of MW.
I’ve created a ticket so we remember to revisit this issue in the future. I’m marking this issue resolved.