nit: "whose return type corresponds to the ZObject's type or to Z1/Object"

To be consistent, we might normalize a function call that should return a string, for example, as the value for a Z6K1. That is (maybe): {“Z1K1”: “Z7”, ...} normalizes to {“Z1K1”: “Z6”, “Z6K1”: {“Z1K1”: “Z7”, ...}}, just as the simple string “Wikifunctions” normalizes to {“Z1K1”: “Z6”, “Z6K1”: “Wikifunctions”}.

If the function call should return a Z1 (rare, I hope), the {“Z1K1”: “Z7”, ...} normalizes naturally to {“Z1K1”: “Z1”, “Z1K1”: {“Z1K1”: “Z7”, ...}}. I don’t think we should simplify that.

In T277913#6930821, @DVrandecic wrote:

nit: "whose return type corresponds to the ZObject's type or to Z1/Object"

Agreed!

To be consistent, we might normalize a function call that should return a string, for example, as the value for a Z6K1. That is (maybe): {“Z1K1”: “Z7”, ...} normalizes to {“Z1K1”: “Z6”, “Z6K1”: {“Z1K1”: “Z7”, ...}}, just as the simple string “Wikifunctions” normalizes to {“Z1K1”: “Z6”, “Z6K1”: “Wikifunctions”}.

Yes, that's a good idea. We should add that to the normalization test suit once it is there. Alternatively, we could make it a well-formedness condition to disallow anything but a JSON string as the value for a Z6K1 key.

In T277913#6982438, @DVrandecic wrote:

To be consistent, we might normalize a function call that should return a string, for example, as the value for a Z6K1. That is (maybe): {“Z1K1”: “Z7”, ...} normalizes to {“Z1K1”: “Z6”, “Z6K1”: {“Z1K1”: “Z7”, ...}}, just as the simple string “Wikifunctions” normalizes to {“Z1K1”: “Z6”, “Z6K1”: “Wikifunctions”}.

Yes, that's a good idea. We should add that to the normalization test suit once it is there. Alternatively, we could make it a well-formedness condition to disallow anything but a JSON string as the value for a Z6K1 key.

I'm confused by this. The way I had conceived of this was as follows (normal form used throughout): a Z6 can be EITHER

1. a Z6 literal, e.g. {"Z1K1": "Z6", "Z6K1": "Wikifunctions"}

OR

2. a Z7 literal that returns a string, e.g. { ..., "Z7K1": { ..., "Z8K2": {"Z1K1": "Z9", "Z9K1": "Z6" }, ... } }

(or a reference, like anything else).

If the Z7 is the value of Z6K1, then the return type of the Z7 is just a raw string instead of a Z6, which doesn't work unless we also want to allow Z6K1 to be kind of a nested Z6, e.g.

{ ... "Z6K1": { "Z1K1": "Z6", "Z6K1": { "Z1K1": "Z6", "Z6K1": "the actual string" } } }

Nesting of Z6/Strings seems perfectly legitimate whilst a “raw string” return type does not. An explicit nesting should probably be removed during normalization but the evaluator cannot rely on this unless it performs the same reduction itself (as I imagine it should) after evaluating nested function calls.

Please note that my proposal is not specific to strings. In effect, it means that normalized objects MUST NOT be Z7s; a Z7 can only be the value* within an object. (And, as I said before, if the Z7’s return type is a Z1, the nesting should not be simplified. Other nesting of Z1s probably should be simplified, just like Z6s and Z9s.)

*also, eventually, the key in a key–value pair or a whole key–value pair (but probably not broader or narrower substrings of objects)

Clarified here [https://meta.wikimedia.org/wiki/Talk:Abstract_Wikipedia/Function_evaluator_call#The_normalized_type]