-
Notifications
You must be signed in to change notification settings - Fork 110
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
base: master
Are you sure you want to change the base?
Conversation
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. |
2930bc7
to
0bba880
Compare
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.
|
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 |
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. |
598f52d
to
e9c523b
Compare
I'm guessing you can remove the call to `rec` now (which is something I was reluctant to merge).
Done
|
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. |
64aaf18
to
b3696f4
Compare
For some reason, my email is not shown in the thread. Re-posting using browser:
Body should not be needed. Though I am not 100% sure about
It would fail. I updated the macro to handle arguments in the last commit.
Not sure. Normalizer did not sound very intuitive for me when I just |
4f5fbc4
to
d0acc8c
Compare
059b10c
to
77b4c2b
Compare
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:
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:This pull request does exactly this.