Issue type:

• ➕ Feature request
• ❓ Question

Issue:

The apply operator seems to always fill in the first slot of the input operator. For static variables and symmetric operators this is not a problem, but it makes forming predicates annoyingly difficult if not outright impossible (my use case does not work in the latest version due to unrelated pipe operator bugs). For example the NBT-value group of operators take the NBT as their first input and the tag name as the second. Forming a predicate for filtering a fixed item by a dynamic tag name is easy:

apply:item->NBT-value

creates a single-input operator which can then be used in e.g. an NBT.hasKey operator to form a predicate and filter a list of tag names.

For the opposite, filtering a list of items by a static NBT key, the solution should be equally simple:

apply:tagName(string)->NBT-value

should form a single-input operator that takes an item variable and returns the value corresponding to the (static/predefined) NBT key. Again this could be piped into boolean relationals to form a predicate for list filtering and similar purposes.

Except the "apply" operator does not have any option to specify the "string" input should be aimed at the second slot of the NBT-value operator, nor does it adjust automatically based on the I/O structure of said operator. Curiously the error thrown by the "apply" result is "received an input with type Operator at position 0 while the type NBT was expected for currying". I would expect this error to cite a "string" type as I am applying a static variable.

Even with the expected capabilities of the "pipe2" operator or nested "apply"/"pipe" operations I do not see how one would circumvent the fundamental issue of needing to leave the first input "dangling" in order to form a predicate.

Thanks in advance for any potential solutions or workarounds.

Doesn't the 'flip' operator solve your use case?

That does work, but it gets cumbersome, especially if you want to apply the third operand, rather than just the second. (Related: my suggestion in #194.)

Doesn't the 'flip' operator solve your use case?

Thank you, didn't know that was a thing! Seems a little tedious having to flip each one individually for chaining but works in version 0.10.3. Probably broken in 0.11.0 for my use case due to #523 or similar piping issues.