@coltim static parsability is usually contrasted not with "rules to resolve ambiguities" but with the need to look up runtime information to determine the structure of the code
@coltim why are you asking? something to do with apl/j?
but if x is "_" there is no left arg? I guess that's the "rules to resolve ambiguities part", like `x` is treated as a scan even if x is not a function (because you can't tell without knowing what x is)
static parsing just says "eh, all variables are nouns" and solves the whole problem, at the cost of making you unable to easily define custom infix functions
couldn't it just throw a run time error? 0_o (I can't tell if I'm just being dense here. I guess that would break chains of UDFs being called but maybe "forcing" it to parse as a[b[c]] would be better?)
hmm, I guess f and x are less relevant. if g is a function then you could try calling g[f;x] and throw an error if that doesn't make sense. if g is data then call g[f;x] and error if that doesn't make sense?
hmm. it may just be semantics then. resolving ambiguities by parsing x y z as x[y[z]] (or noun-noun-noun I guess), or z x\y as x\[z;y] "allows" the language to be statically parseable
I've always just gotten tripped up by using \ as a function, and haven't quite puzzled out all the nuances there. at least I think I'm pretty close to understanding . =P
yeh, I'm probably just missing something. I understand that there is a grammar that defines the high-level stuff but I'm more interested in the gnarly bits like 0.1/.1/.a/a.b/a.1/,.x/(,).x/2000.01.01 and how those are handled
or rather, where the limits are with that sort of stuff, lol
hmm, yeh, that's probably what I get tripped on. like the result feels similar (i.e. the role something takes on varies depending on what it's surrounded by) even if the process is different