141–150 of 272 posts
Why even have commas at all? This is a non-issue for the likes of Tcl and Lisp and your average shell-scripting language and what have you; whitespace is already a good enough delimiter.
That said, generating SQL from s-expressions can be a very pleasant experience.
Earlier quoted context omitted.
in 20 years of writing SQL, preceding commas is so much better IMO. Its so easy to miss a comma at the end of a long expression. preceding commas means you can never forget them. Then if I can have an extra leading comma, I can reorder, comment out or remove, or add a column at any point in the list without having to think about the rest of the projection. Also diffs are cleaner, it only highlights the rows that have…
It's only easy to miss a comma at the end of a long expression because you need to calculate whether it should be there in the first place. If commas were always required unconditionally, it wouldn't be a problem.
Earlier quoted context omitted.
The limitation is clearly not Rust. Any language that can bind to C libraries can bind to the functions PRQL exposes... the authors just haven't chosen to implement convenient SDKs for many languages. They also list 8 languages, not 4, just that they've had time to polish the libraries for 4 languages, apparently. PRQL appears to be a rather small project... not some major corporate effort.
I wouldn’t mind writing the C bindings myself, but the docs say that not even C is officially supported.
C bindings would be great! Do you want to open an issue in the repo?
I feel the problem. When coding (not only in SQL) you often have to add something to the end of a list, and it is annoying that the end of the list is always special. You can't just copy some line and move it there. Also when moving things around you always have to take extra care at the end. So, my solution for this was always SELECT a , b , c FROM ... instead of: SELECT a, b, c, -- people want to allow trailing com…
Mode Analytics published some data years ago showing that SQL programmers who preferred leading commas had a lower rate of errors than programmers who used trailing commas. [0] 0 - https://mode.com/blog/should-sql-queries-use-trailing-or-lea...
Earlier quoted context omitted.
I wouldn’t mind writing the C bindings myself, but the docs say that not even C is officially supported.
Hi, PRQL contributor here. C bindings would be great! Do you want to open an issue in the repo?
Earlier quoted context omitted.
Alright, it supports four languages, but that’s still not much.
The limitation is clearly not Rust. Any language that can bind to C libraries can bind to the functions PRQL exposes... the authors just haven't chosen to implement convenient SDKs for many languages. They also list 8 languages, not 4, just that they've had time to polish the libraries for 4 languages, apparently. PRQL appears to be a rather small project... not some major corporate effort.
The main limitation is developer time. There is so much that could be done with PRQL! Without corporate sponsor, parent company, or more contributors, velocity is unfortunately limited. If you'd like to see that change, please reach out!
Earlier quoted context omitted.
Hi, PRQL contributor here. C bindings would be great! Do you want to open an issue in the repo?
Sorry, by my comment I meant that if PRQL exposed a C API (as the parent commenter claims it does), I’d write bindings for the languages I use that can consume C libraries. Unfortunately I’m not proficient enough with Rust to create the C API myself.
There was also a helpful comment on a HN thread a few weeks back about how to make the API better to develop against. I've been meaning to get back to that but been constrained myself.
Why even have commas at all? This is a non-issue for the likes of Tcl and Lisp and your average shell-scripting language and what have you; whitespace is already a good enough delimiter.
Because there's existing implementations that would interpret that as aliasing column names. ``` SELECT Field AS Renamed, OtherField AS AlsoRenamed ``` and ``` SELECT Field Renamed, OtherField AlsoRenamed ``` are semantically equivalent.