refactor alternate query syntax parsing into a seperate package

[natask]

I found utility in using your alternate query syntax in my projects. It is a convenient to use, specially in consult or helm. It has a one to one mapping with s-expression. Therefore, It can be tossed around internally and operated on natively. Are you interested in splitting it off into a different package. I am sure others would find it useful. For example searching in org-roam.

[alphapapa]

Hi,

I'm glad it's been useful to you. I don't think it's actually a complete 1:1 mapping with sexps, e.g. it doesn't support parenthetical sub expressions, alists, etc. It only supports what's been needed in org-ql so far.

I don't think splitting it out would be good. It would be another dependency for this package, and another thing to have to keep in sync if meaningful changes were made. It's only a few functions, so I think anyone who wants to use it should copy the code into their project and modify it according to their needs.

[natask]

Yes, only after #251 would It would be 1:1.

I see. I plan on loosely maintaining a separate repo because It would be convenient for me to utilize and manage within multiple projects. I will post a link on here when I get around to it.

[alphapapa]

It still wouldn't always be 1:1, because a sexp query can contain arbitrary expressions, such as calls to any Lisp function or macro. But for a limited "vocabulary," yes, it could be 1:1, I think.

That's cool, please do link it when you're done. I'm happy to see your doing that, it's just that maintaining a kind of "non-sexp sexp syntax converter" library isn't something I want to take on. There are already enough of those kind of alternative-Lisp-syntax projects out there. :)

[natask]

There are already enough of those kind of alternative-Lisp-syntax projects out there. :)

haha, I don't have the ambition to take on S-expressions (and lose like the countless and forgotten alternative lisp syntax projects). I assure you it will remain limited in scope. I only need it to describe boolean expressions.

[natask]

I have the package here. it is rudimentary. I have only modified and tested sexp-string--define-query-string-to-sexp-fn and sexp-string--define-transform-query-fn. I am using it in org-roam-search and it works nicely.

As a side note, this is the function to simplify expressions you were looking for in #251.

[alphapapa]

@natask Thanks.

Since you copied a significant amount of code and comments directly from this package, you should probably list my name in the copyright statement in the headers. And you should make comments of your own pointing out what was copied and from where.

Also, FYI, there's a thread on emacs-devel with Stefan Monnier and Helmut Eller where we've been discussing some improvements to the peg.el API (the discussion continued in private email), e.g. for returning an optimized parsing function that can be called later to parse a string.

[alphapapa]

@natask Looking more carefully at this recent commit: natask/sexp-string@dd73bcd There are a few issues:

1. Please don't list me as a maintainer of your package. The reason you made it is that I don't want to factor it out into another package myself. In contrast, listing me as one of the authors is fair, since large portions of the code and even comments were copied wholesale from org-ql.
2. I see that you started off with the LICENSE file listing an MIT license, and now have added the GPLv3 to it, saying that some--unspecified--parts are licensed under GPLv3. That is not an acceptable way to copy GPL-licensed code into a non-GPL-licensed project. My code in org-ql cannot be relicensed to MIT by you; only I could do that, since I hold the copyright to it. By copying code from my project, a GPLv3 one, into your project, your project needs to be GPLv3-licensed as well. If you don't want to use the GPLv3 license, you should remove all GPLv3-licensed code from your project. Looking at the code now, it appears that 90-95% of it, code and comments and docstrings, is copied directly from org-ql, so I don't see how your project could reasonably use the MIT license to any extent.
3. Your Elisp file lacks license information in the comments, so users who would receive the code without the accompanying LICENSE file would have no knowledge of the license.

Having contributed a few small patches to Emacs, and now a package in GNU ELPA that has copyright assigned to the FSF, I am trying to be more careful about copyright and licensing in my projects. Please do be careful with how you use others' code in your projects as well.

[natask]

@alphapapa My apologies, I didn't intend to misappropriate your license. My intention was to release my portion such that others can do what ever they please with it. I don't know much about copyright licenses. I wasn't aware that a project that uses GPLv3 licensed code needs to be licensed under GPLv3 as well.

I will license the project under GPLv3.
Thank you for taking the time to put these issues in my radar. I will incorporate your suggestions.

Although I don't think that the project, given its limited applicability and fixed scope, warrants delving into copyright, it is nevertheless worth the experience. Better to learn on the small things.

[alphapapa]

@alphapapa My apologies, I didn't intend to misappropriate your license.

Of course, I didn't think you did so on purpose.

My intention was to release my portion such that others can do what ever they please with it.

This might be an opportunity for you to review why people choose the GPL over "permissive" licenses like MIT/BSD. Those licenses permit others to take the code, modify it, and release the modified software without the source code, so that users of the software can no longer modify or redistribute it. In other words, MIT/BSD give developers (or big companies) more freedom, but they give the users of the software less freedom. From another perspective, those licenses don't respect users of software as developers, or potential developers, of it; those users may be left beholden to the whims of others.

I don't know much about copyright licenses. I wasn't aware that a project that uses GPLv3 licensed code needs to be licensed under GPLv3 as well.

Yes, MIT or BSD code can be relicensed under the GPL, but GPL code cannot be relicensed under MIT or BSD. (Some people refer to the GPL as "viral" for this reason, implying that it spreads to other code; but, of course, that's always a conscious decision by those who apply the license or use GPL-licensed code.)

I will license the project under GPLv3. Thank you for taking the time to put these issues in my radar. I will incorporate your suggestions.

Thanks.

Although I don't think that the project, given its limited applicability and fixed scope, warrants delving into copyright, it is nevertheless worth the experience. Better to learn on the small things.

If it were all your own code, sure, you might even want to place it in the public domain, "unlicense," CC0, etc. Again, just be aware that would mean that the code could be taken "hostage" and users of the software could have their rights taken away.