Comment by naasking
3 days ago
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!
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.