Re: Difference :header-args: and :header-args+:?

[Achim Gratz <Stromeko@nexgo.de>]

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.

> As to the non-scalability, that should be fixed by some combination of
> the parser cache and retrieving all properties at once (via
> ‘org-entry-properties’) rather than ‘org-entry-get’-ing them
> one-by-one.

I don't think that will solve the problems.  Note that the new syntax is
dealing with default header args via the property facility just the same
and the only real change is that it makes it possible to separate
different Babel languages as well as defaults for all languages.

> 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 also important for caching
since the cache signature for results doesn't take default headers into
account.  If you want to fix header args for certain block you can
already do so by just specifying the header arg directly with the surce
block.  If you absolutely must use properties for this, you can simply
do something like

:var test=(org-entry-get nil "property" 'inherit)

to pick up a property at the site of definition.  But then at least it
is explicit.

> The first demonstration in the attachment (not related to #+calls)
> seems like a much clearer case of deficiency of the new system: an
> inability to inherit different args from different levels.

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.

>> <orgmode.git>/testing/examples/ob-header-arg-defaults.org
>
> I find the content of this file incredibly dense, and the suggestion
> of its use as documentation bordering on a joke.

I wasn't offering it as documentation, only as a means to figure out
what is or isn't supposed to be working.  Plus it does boil down the
whole topic into the smallest possible space.  And if you do that you'll
see that inheritance across multiple levels has not been tested so far
(also not all possible combinations of shadowing), only inheritance
between global and tree properties.

> (Documentation may
> not exist, and that just means an area for improvement has been found.
> But it’s not as though we’re all going to read that file and suddenly
> understand what you mean.)  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.

> That is a very confusing interaction (to name just one).  It’s also not
> clear to me how it relates to other header args, since vars supplement
> each other, whereas other types of header replace.

The other header args are treated exactly the same, it's just that
whatever their latest definition "wins" and you never see the other
definitions.  Properties are just strings right until babel interprets
them as header args.  If you print the complete properties as they get
seen by the source block, you'll see this.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada