org-ql-defpred-alias: Simplified custom predicates

[yantar92]

When creating custom predicates, I often found that they are usually simply aliases to some org-ql query. No fancy predicates or preambles are needed.

A typical proper custom predicate looks like:

(org-ql-defpred goal ()
    "Match a goal."
    :normalizers ((`(,predicate-names)
    	       (rec '(tags-local "goal"))))
    :preambles ((`(,predicate-names)
    	     (rec '(tags-local "goal")))))

I have to defer normalisation and preamble to existing predicates for efficiency.

The above code is repetitive, especially when one uses queries more complex compared to (tags-local "goal") in this example. It would be nice to write something like yet benefiting from preambles:

(org-ql-defpred-alias goal ()
    "Match a goal."
    (tags-local "goal"))

This pull request does exactly this.

[alphapapa]

This is an interesting idea. I'd like to give it some more thought before merging. Anyway, IIUC this patch is based on changes that haven't been merged yet, so it shouldn't be based on my master branch.

[yantar92]

alphapapa ***@***.***> writes:

Anyway, IIUC this patch is based on changes that haven't been merged yet, so it shouldn't be based on my master branch.

Oops. I accidentally messed up my pull request local branch. Should be fixed now. This change does not require any unmerged changes.

[alphapapa]

This idea will probably be more viable since merging 482a5c9, because now normalizers are run repeatedly until a query reaches a final form. I'm guessing you can remove the call to rec now (which is something I was reluctant to merge).

[alphapapa]

As well, it shouldn't be necessary to specify any preambles now. Just normalize the predicate to the desired form, which can provide its own preamble.

[yantar92]

I'm guessing you can remove the call to `rec` now (which is something I was reluctant to merge).

Done

[alphapapa]

Thanks. I think this idea has potential, but it needs more fleshing out. For example, in the example you gave, the predicate is normalized away, so a body form isn't even necessary. Are there any cases in which that's not what should be done? Should a body form even be allowed?

As well, what about arguments? The example you gave doesn't accept any, but the macro offers to accept them. What would happen if a user tried to use the macro to define a predicate alias that does accept arguments?

Should this be limited to just defining a normalizer? If so, should that be in its name?

What do you think? Thanks.

[yantar92]

For some reason, my email is not shown in the thread. Re-posting using browser:

Thanks. I think this idea has potential, but it needs more fleshing out. For example, in the example you
gave, the predicate is normalized away, so a body form isn't even necessary. Are there any cases in which
that's not what should be done? Should a body form even be allowed?

Body should not be needed. Though I am not 100% sure about children,
parent, and especially descendants predicates. I had issues with
them in the past, partially because I do not fully understand how they
work.

As well, what about arguments? The example you gave doesn't accept any, but the macro offers to accept
them. What would happen if a user tried to use the macro to define a predicate alias that does accept
arguments?

It would fail. I updated the macro to handle arguments in the last commit.

Should this be limited to just defining a normalizer? If so, should that be in its name?

Not sure. Normalizer did not sound very intuitive for me when I just
started playing with predicates. I imagine org-ql-defpred-alias as a
light version of org-ql-defpred for more casual users. On the other
hand, normalizer instead of alias may be more consistent with existing
terminology. I am leaning towards alias, though it is not very strong
stance.