I just came across a post <https://www.oilshell.org/blog/2018/11/30.html> on tabular data structures in R, Python, and SQL. The post is written has a friendly intro to the subject, which the author claims is a gap that needs filling. Thus, the post might not contain much information that is new to this group. Perhaps the opportunity is for the Racket community to use that friendly intro as a springboard to a comparison for how to approach tabular data in Racket.
On Saturday, March 16, 2019 at 3:54:51 PM UTC-7, jackh...@gmail.com wrote: > > Hooray! Now we're up to 7 tagged packages > <https://pkgd.racket-lang.org/pkgn/search?tags=tabular> (that was fast!) > > On Saturday, March 16, 2019 at 12:13:38 PM UTC-7, johnbclements wrote: >> >> Yep, excellent idea. I’ve added the ’tabular’ tag to csv-writing. >> >> John >> >> > On Mar 15, 2019, at 3:24 AM, jackh...@gmail.com wrote: >> > >> > I think we should all work towards making our existing code in this >> area more discoverable, so we can get a better sense of what libraries for >> working with tables exist in the wild. To those of you who own Racket >> packages that provide any functionality related to data tables: I recommend >> adding the "tabular" tag to your package's description in the package >> catalog. There's no need to remove more-specific tags (like "data-frame") >> from your package, but even if you have a more specific tag please include >> the general "tabular" tag so it's easy to search for your package. So far >> there's only 3 packages tagged with "tabular" (and one of those is a >> package of mine that I just tagged while writing this post). I see several >> packages that are good candidates for the tag: >> > • data-frame >> > • sqlite-table >> > • table-panel >> > • tabular >> > • rml-core (maybe?) >> > • sinbad >> > • spmatrix (maybe?) >> > • spreadsheet-editor >> > • csv >> > • csv-reading >> > • csv-writing >> > • simple-csv >> > • Most things with the "sql" tag >> > The more packages we have tagged and documented, the easier it will be >> to find real code using tables in the wild. Which is information we'll need >> if we want to understand how a standard `racket/table` API might look. >> > >> > On Thursday, March 14, 2019 at 10:28:41 AM UTC-7, Ryan Kramer wrote: >> > On Thursday, March 14, 2019 at 12:26:39 AM UTC-5, Alex Harsanyi wrote: >> > >> > There are now several projects announced on this list, all of them deal >> with >> > data analysis on one way or the other. Would it be possible to join >> forces >> > and merge these projects so that we end up with one library that >> servers >> > multiple purposes equally well? Something where the final product is >> greater >> > than the sum of its parts... >> > >> > Or perhaps these libraries have aims that are so different from each >> other >> > that the only thing they share is a very abstract concept of "table"? >> > >> > I think my project "plisqin" is one of those you are thinking of. >> Matt's "tbl" is also one. I'm also keeping an eye on Ryan's "sql". Are >> there any more you were thinking of? >> > >> > Regarding joining forces/merging these projects, this is a good >> question that I think warrants discussion. So I'll share my thoughts. >> > >> > Obviously I can't speak for all of us, but right not I only see the >> "very abstract concept of "table"" as potential shared code. (Also, >> learning about snip% earlier in this thread was awesome. I'd love to use >> something like that in my project.) >> > >> > I think the differences between plisqin and tbl are fairly obvious - >> plisqin is an alternative to SQL while tbl is an alternative to >> "Python/NumPy/SciPy, or R/Tidyverse (or, horrors, plain R)" >> > >> > Now comparing Ryan's sql to plisqin is a different story. These >> projects are both alternatives to SQL. But I think there is enough >> difference between our approaches and scope to warrant separate projects, >> at least for now. >> > 1) sql seems to be mostly implemented as macros. plisqin is mostly >> implemented as procedures. >> > 2) plisqin has some design decisions that some might consider "too much >> magic", namely inline joins and "inject-able aggregates" (need better name) >> as documented here: https://docs.racket-lang.org/plisqin/intro.html. >> Whereas sql-the-package seems to more closely mirror SQL-the-language - it >> would be difficult to surprise yourself with the SQL you generate. >> > 3) I am trying to design #lang plisqin so that people with no Lisp >> experience can use it. (Whether I will succeed is another matter...) >> > >> > I apologize to Ryan C if I have mischaracterized sql. I'd like to have >> a longer conversation about this, but maybe this list is not the right >> place. (Also, Ryan, if you think our goals are more similar than I do, I'd >> be happy to work with you. You're definitely a more experienced Racketeer >> and it would surely boost my code quality.) >> > >> > - Ryan Kramer >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "Racket Users" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to racket-users...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
