// Computes the delivery date for each component.
let r = query p select (c, d) from ReadyDate(c; d)
query p from ReadyDate(c; d) select (c, d)
Path(x, z) :- Path(x, y), Edge(y, z).
query p select (x, z) from Path(x, y), Edge(y, z).
A. Keep the logic rules and `query` construct consistent (i.e. read from right-to-left).
B. Reverse the logic rules and query construct-- thus breaking with decades of tradition established by Datalog and Prolog.
C. Keep the logic rules from right-to-left, but reverse the order of `query` making it from left-to-right.
We decided on (A), but maybe we should revisit at some point.
1. I think way more people coming to your language will be familiar with SQL and it's problems than with logic programming and Horn clauses.
2. I think many people are now familiar with functional pipelines, where filters and transforms can be applied in stages, thanks to the rise of functional programming in things like LINQ and Java's Stream API. This sort of pipelining maps naturally to queries, as LINQ has shown, and even to logic programming, as µKanren has shown.
3. People don't type programs right-to-left but left-to-right. To the extent that right-to-left expressions interfere with assisting the human that's typing in various ways (like autocomplete), I would personally defer to helping the human as much as possible over historical precedent.
4. Keeping the logic fragment separate from the query fragment (option C) seems viable if you really, really want to maintain that historical precedent for some reason.
My two cents. Kudos on the neat language!
I think when it comes to programming language design, sometimes I feel that a design has a 90% chance of being good and a 10% chance of being bad. For the logic constraints (right-to-left vs. left-to-right), I think my confidence is only 70% that we got it right.