Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

org-ql-defpred-alias: Simplified custom predicates #211

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

yantar92
Copy link
Contributor

@yantar92 yantar92 commented May 1, 2021

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
Copy link
Owner

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.

@alphapapa alphapapa self-assigned this Jun 3, 2021
@alphapapa alphapapa added this to the Future milestone Jun 3, 2021
@yantar92 yantar92 force-pushed the feature/org-ql-defpred-alias branch 2 times, most recently from 2930bc7 to 0bba880 Compare June 20, 2021 14:43
@yantar92
Copy link
Contributor Author

yantar92 commented Jun 20, 2021 via email

@alphapapa
Copy link
Owner

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
Copy link
Owner

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 yantar92 force-pushed the feature/org-ql-defpred-alias branch 2 times, most recently from 598f52d to e9c523b Compare July 3, 2021 06:46
@yantar92
Copy link
Contributor Author

yantar92 commented Jul 3, 2021 via email

@alphapapa
Copy link
Owner

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 yantar92 force-pushed the feature/org-ql-defpred-alias branch 2 times, most recently from 64aaf18 to b3696f4 Compare August 10, 2021 06:09
@yantar92
Copy link
Contributor Author

yantar92 commented Sep 5, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants