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

Support toml #271

Open
cathaysia opened this issue Mar 24, 2025 · 4 comments
Open

Support toml #271

cathaysia opened this issue Mar 24, 2025 · 4 comments

Comments

@cathaysia
Copy link

Could you add support toml? Or will you accept such PR?

@01mf02
Copy link
Owner

01mf02 commented Mar 24, 2025

Hi @cathaysia, I plan to add support for this format (like YAML #10 and XML), but it is currently not very high on my list of priorities, so by default, it will probably still take a few months before I will work on it. I will still need to figure out how to adapt the CLI and the internal data types how to make these things happen. So working on a PR from your side is a bit of a risky game, but ... if you are able to make a function like jaq_json::Val::parse, with a signature parse_toml(...) -> Result<jaq_json::Val, String>, then I'd definitely consider it, and it might speed up the integration of this feature. I just can't promise to expose this functionality immediately.

@cathaysia
Copy link
Author

Thanks for your reply. It's great to see that you have plans to do this. But considering that adding these too early may bring burden to the following refactoring, I might prefer to wait until your interface is stable before looking at these.
But on the other hand, I may not have much time to do this. Haha

@cathaysia
Copy link
Author

I haven't studied jaq's code in depth. But based on my past experience, if the existing interface is difficult to adjust, then you may consider adding another layer of abstraction (such as HIR). For example, expression -> compile -> hir -> json (yaml/toml)

@01mf02
Copy link
Owner

01mf02 commented Mar 28, 2025

Thanks for your reply. It's great to see that you have plans to do this. But considering that adding these too early may bring burden to the following refactoring, I might prefer to wait until your interface is stable before looking at these.

I think that this is a good idea. :)

I haven't studied jaq's code in depth. But based on my past experience, if the existing interface is difficult to adjust, then you may consider adding another layer of abstraction (such as HIR). For example, expression -> compile -> hir -> json (yaml/toml)

I think that the internal interface will not be that hard to adjust. It's more about figuring about how users can use the functionality. For example, when you use include "foo" as $foo; in a filter, this will load foo.json and expose it as $foo. When adding support for new formats, such as TOML, should users be allowed to load a foo.toml using include "foo" as $foo; as well? What if there is foo.toml and foo.json? Or should users be able to load files via include "foo.toml" as $foo;? And that is only one problem of many to figure out --- scratching the top of the iceberg. At the same time, I would like to remain compatible with other jq implementations, such as fq, so I always do some research and coordination, which also takes time and effort.

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

No branches or pull requests

2 participants