Re: [O] Difference :header-args: and :header-args+:?

[Aaron Ecay]

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