[jorkadeen]

It is a fair point-- the implicit argument being that this allows `c` and `d` to be bound before they are used, and hence auto-complete can assist in the `select` clause. Nevertheless, the counter argument is that the form of a logic rule is:

  Path(x, z) :- Path(x, y), Edge(y, z).

i.e. an implication from right to left. This structure matches:

  query p select (x, z) from Path(x, y), Edge(y, z).

So the trilemma is:

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.

[naasking]

I appreciate the desire for consistency and being able to lean on old textbooks and documentation. A couple of considerations since this is a new language where history and precedent should (I think) be less important if it leads to clarity and improved productivity:

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!

[jorkadeen]

All excellent points.

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.