I discovered Racket through Exercism, and now I’m using it at work, so I can definitely recommend it.

Is there anything in Racket that’s like Python’s OrderedDict? An OrderedDict in Python is a dictionary that preserves insertion order when iterating. In Python3.6 onwards, they made the standard library’s dictionary behave that way by default, it was faster for them. I don’t care much for the speed, but I find the behavior quite useful.

As in, for/hash would receive the keys/values in the same order as insertion

In the meanwhile, a list of pairs works for me, it’s fairly simple to write functions to work on that.

@hoshom there’s a pkg for that

I think it’s called ordered-hash

Switching from contracts to types make types feel clunky (contracts were amazing! satisfying the type checker is so much work), switching from types to contracts make contracts seem so primitive (all my dear guarantees are gone! what’s with all these runtime checks), but switching from having nothing to any one of those feels soooooo empowering :smile:

@samth nope must be something else

It’s called ddict

@samth thank you so much for typed racket btw

And there’s also dset

found ddict, thanks!

How does the package server tag packages?

@samth Oh I thought you were going to suggest data/splay-tree https://docs.racket-lang.org/data/Splay_Trees.html or or data/skip-list https://docs.racket-lang.org/data/skip-list.html

@hoshom tags are added by package authors

Right, basically I was looking for a place to add a suggestion/pull-request kinda thing, saying “it would be nice if this package is searchable by terms like dictionary, ordered dictionary, hash”. Anyway that’s fine.

@hoshom I think you could email the package author; I think most or all pkgs have email addresses? (But I agree a PR or “suggest tag” UI in the pkg web site would be nice.)

BTW I mentioned splay-tree and skip-list because it looks like ddict is ordered LIFO, in case that matters? (Maybe you want LIFO. Or maybe it’s sufficient to have some order, e.g. when writing unit tests.)

Having said all that I am super ignorant of, say, the pros and cons of splay trees and skip lists and so on. I’m not recommending, just pointing out. :smile:

For now I’ve just powered on with my assoc-list and not used any package :blush: I hope to have this thing I’m working on submitted to the package server in a few days, so I’ll feel less bad about asking so many things here :smile:

I did note the LIFO part but I figured as long as I know the order it’s fine, I can always reverse in the end

@hoshom out of curiosity, what are you working on that requires an insertion-ordered dict?

@soegaard2 let’s go with your plan. I don’t think Textmate people are going to merge that PR soon.

@notjack Sooo what I do is I maintain a data structure that allows me to present an interface for “query”-ing data, and holds enough information to be able to rendered to SQL later on. Part of that information is a “list of join-graphs”. I can ask my query to include columns. These included things are “qualified columns”, as in, they’re prefixed by either a table or a list of relations from that table leading to another. Whenever I ask my query to “include” something across multiple relations, I check if the path represented by those lists of relations exists in one of the join-graphs and if it does, it just adds the column, and if it doesn’t, it also adds the missing tail of the path into the relevant graph. When I actually get around to rendering the SQL, I iterate my list of graphs breadth-first and map each path-to-node to a string. This way when rendering columns I always know how to refer to the name of the relation-path that is the column’s prefix. When I render the joins, instead of iterating my list of graphs again, I simply iterate over this map, because the map was made via iterating breadth-first, which means that as long as I iterate in insertion order, previous relations won’t refer to future relations that haven’t been rendered yet.

@hoshom I don’t follow the details, but I think I get the general idea you’re going for. Would it help you if you had a library for dealing specifically with directed acyclic graphs? It sounds like that kind of logic is embedded in a lot of that domain.

I dunno, really. Overall what I’m trying to do is have a “language” to allow client programs to query relations more naturally. Relations do form graphs. But I think the graph part is done now.

A lot of the difficulty is simply translating to sql without losing expressive power on either side.

That makes sense

there’s a sql package for writing sql queries with s-expressions, you might find that useful

but it sounds like you’re making something that’s more dynamic

Umm, “losing expressive power” is misleading. What I don’t want to lose is the ability to let the client specify related columns, and/or filter based on related columns, while providing pretty much all of sql as far as filters go, but doing the right thing in terms of getting joins, optimizing, etc. so that the result is the one I want. And what I want is pretty unambiguous. The closest thing I had before this was in Python/Django/Django-ORM, where I leveraged django’s relation lookups to do much of the heavy lifting. That worked brilliantly, but there were some pretty solid walls I hit that didn’t allow me to do the additional things I wanted for future projects. Before that I’d done similar work in Python/SQLAlchemy, which has a more robust and flexible query builder, so it didn’t have the same limitations as the django version, but it still had some fairly fundamental limitations, and didn’t have the auto-relation-lookup thing done as comprehensively as django so there was less to leverage.

@notjack yeah I saw the sql package, but for now I don’t need it. I do think I’ll want to switch to it later, but that will be easy.

Another package that seems to have goals similar to mine is plisqin but my approach is different. I’ll see where we end up.

I’ve done a little sqlalchemy muddling so this is an interesting space to me, but I don’t have much experience with it

is any of your project’s code open source?

Not yet. I will open source all of this sql/relations part, and I thought I’d do so this week, but this week is looking less likely. Maybe on the weekend, or next week. Though I don’t expect it to be very useful until some more work’s done.

… I find it funny how I can use “open source” as a verb.

no rush, though whenever you get around to it feel free to let me know :)

Sure, will do

@notjack btw what I mean by not “need”-ing the sql package was precisely this: what I’m making is more dynamic, and the reason it ought to be “easy” to switch to the package later on is that it’ll only be there to pass through at the very end, so that (a) I can be more certain of the well-formed-ness of my sql across more than one database and (b) my tests no longer have to run against strings.

The db package’s groupings/group-rows functionality is gonna be a bit of a lifesaver though :phew: It’s technically a workaround for what I originally wanted, but what I originally wanted isn’t implemented anywhere else except postgresql’s own client (psql) so this is about as good as it gets.