Hi Achim, 2014ko irailak 9an, Achim Gratz-ek idatzi zuen: > > Aaron Ecay writes: >> Can you say more about the corner cases? > > It's been quite some time since I looked at this, but inline calls were > quirky for instance since their point of call is ill-defined.
Surely the point of call is just where they are written in the buffer? In any case, I’ll just take your word for it that there are unspecified difficulties. [...] >> Most computer languages with which I’m familiar (Python, R, >> C, Scheme/Lisp, ...) use lexical scoping by default, and elisp has been >> slowly but steadily moving in that direction for years. Thus this new >> suggested dynamic-type behavior for header args is surprising to me. > > There isn't even an execution model for Babel, so this discussion is > going nowhere. Anyway, the idea was that when you look at a Babel > invocation, you should be able to figure out the default header args at > that point without actually having to trace the execution all the way > down to the last recursion level. That’s one point of view. The other is that you should be able to specify a babel block’s behavior fully (i.e. including header args) and know that it will have that behavior no matter where it is called from. I think this system better promotes writing modular babel documents. > That's also important for caching since the cache signature for results > doesn't take default headers into account. But this issue is orthogonal to how the default headers are calculated, isn’t it? [...] > > No, it doesn't demonstrate this. Try to accumulate something to the > commenr property via comment+ at the lower level and convince yourself it > fails in exactly the same way: only the lowest level is returned as the > value of the property. > > That looks like a bug in the property API. When getting the property it > determines that the property is defined at the lowest level and then > doesn't ascend into the upper ones. But even the examples in the manual > show that the entry should add to the higher level definition of the > property if the +-variant is used. The problem is that > org-entry-get-with-inheritance uses org-entry-get (with the inheritance > parameter set to nil), but has no provision to check for the "+" on the > property. OK, I see. With this bug fixed, the new system probably has similar power to the old one indeed. (Modulo the point of definition vs. point of call issue.) [...] >> It looks like it is trying to demonstrate >> inheritance and overriding of :var header args. I can’t figure out >> why the #+call in “Overwrite” gets go1, but the addition of “var+ to1” >> in “Accumulate” causes this to shift, not to “to1”, but to “ge1”. > > The most specific layer is ge1. While go1 is shadowed by to1 in the > same layer, this is then again shadowed by ge1 (the more specific > layer). Shadowing only happens in the same layer, which are overlaid > only just before the invocation. Add :var+: "to3" and remove the > t3="th3" definition to see this in action. Sorry, I still don’t get it. I guess this is just a wart of the interaction between the two systems; let’s hope it disappears as soon as possible. -- Aaron Ecay
