In the case that the most recent seminfo is a numeric constant, we probably want to throw a syntax error. It's unclear if {..77} should be interpreted as {[77]=77}, or {["77"]=77}, and, neither interpretation seems likely to be that useful in practice.
Though now that I think about it, having
print(..f(i))
be valid, while throwing an error on
print(..f(1))
is a little weird. I'm pretty certain that, in the cases where we encounter an undefined seminfo.ts, seminfo.r must be holding a numeric constant. So replacing the codestring() call with
init_exp(&key, VKNUM, 0);
key.u.nval = ls->t.seminfo.r;
should be a fairly reasonable way of handling the situation.
But, as I said earlier, I'm really not convinced that any kind of support for complex expressions is a good idea -- throwing an error anytime the _expression_ ends up parsing more than a single name token would feel cleaner.
-Sven
