ggsql developer here. It's quite fun to see an alternative implementation of our syntax so early. Why did you decide on this path rather than working with the ggsql duckdb extension? (honest curious question - not trying to push you away from your path)
I can only imagine the load you might end up in if you have to keep feature parity with ggsql along with all the other features you have
If you're interested, this isn't an alternative implementation of ggsql's syntax (I published this last year and it is based on a slightly modified layered grammar), but the SGL language is a similar take on the grammar of graphics + SQL idea: https://arxiv.org/pdf/2505.14690.
Currently implemented as an R package: https://sgl-projects.github.io/rsgl/index.html.
Well done for laying that down in that way!
I'm just wondering how much it would be on my side to support that, since I can see that you support cases like "count(*)" and "group by" inside visualize. I can see you have a full bison grammar, I only have a custom parser at the moment, but at least your implementation is in C.
But I'm happy to follow thomasp85.
First of all, nice to meet you! The honest answer is timing: the first VISUALIZE commit on my side was april 25th; ggsql-duckdb's first commit was April 23rd. So I genuinely didn't know it existed!
About the name: yours is the official Posit one, and you were there first, so I'll rename my branding; there should be one ggsql, and it's yours. Mine only exposes VISUALIZE as the keyword anyway.
The actual name of the extension is the-stats-duck, which runs inside duckdb-wasm (it powers an in-browser data tool) and emits a Vega-Lite spec inline for the host to render.
Your implementation (which I think is Rust based and an in-process HTTP server that opens a browser), is a native pattern, but correct me if I'm wrong! mine is deliberately thin and wasm-safe, not a whole engine.
About the parity, you're right, and I'm not chasing it; for real grammar-of-graphics, ggsql should be the tool! but, if that's ok with you, I'd love to keep the syntax aligned!
No objections at all. But probably good to describe that it is ggsql-inspired rather than a full reimplementation as it could lead to user confusion about what syntax is supported etc
And you are correct about how our extension is implemented and it isn’t currently wasm ready
Appreciate it, good call! I'll rename the ggsql bits and the docs to describe it as ggsql-inspired. I'll also point to ggsql for the real thing. Thanks for being kind about it!
That's exactly the inspiration! I made a post here on HN about that a few weeks ago: https://news.ycombinator.com/item?id=48108815
My plan is to release a blog post about all VISUALIZE current features next week, explicitly mentioning Posit's alpha GGPLOT.
/edit: clarifications
ggsql developer here. It's quite fun to see an alternative implementation of our syntax so early. Why did you decide on this path rather than working with the ggsql duckdb extension? (honest curious question - not trying to push you away from your path)
I can only imagine the load you might end up in if you have to keep feature parity with ggsql along with all the other features you have
If you're interested, this isn't an alternative implementation of ggsql's syntax (I published this last year and it is based on a slightly modified layered grammar), but the SGL language is a similar take on the grammar of graphics + SQL idea: https://arxiv.org/pdf/2505.14690. Currently implemented as an R package: https://sgl-projects.github.io/rsgl/index.html.
Well done for laying that down in that way! I'm just wondering how much it would be on my side to support that, since I can see that you support cases like "count(*)" and "group by" inside visualize. I can see you have a full bison grammar, I only have a custom parser at the moment, but at least your implementation is in C. But I'm happy to follow thomasp85.
First of all, nice to meet you! The honest answer is timing: the first VISUALIZE commit on my side was april 25th; ggsql-duckdb's first commit was April 23rd. So I genuinely didn't know it existed!
About the name: yours is the official Posit one, and you were there first, so I'll rename my branding; there should be one ggsql, and it's yours. Mine only exposes VISUALIZE as the keyword anyway.
The actual name of the extension is the-stats-duck, which runs inside duckdb-wasm (it powers an in-browser data tool) and emits a Vega-Lite spec inline for the host to render. Your implementation (which I think is Rust based and an in-process HTTP server that opens a browser), is a native pattern, but correct me if I'm wrong! mine is deliberately thin and wasm-safe, not a whole engine.
About the parity, you're right, and I'm not chasing it; for real grammar-of-graphics, ggsql should be the tool! but, if that's ok with you, I'd love to keep the syntax aligned!
No objections at all. But probably good to describe that it is ggsql-inspired rather than a full reimplementation as it could lead to user confusion about what syntax is supported etc
And you are correct about how our extension is implemented and it isn’t currently wasm ready
Appreciate it, good call! I'll rename the ggsql bits and the docs to describe it as ggsql-inspired. I'll also point to ggsql for the real thing. Thanks for being kind about it!