4 ms·
This is why we can't have nice things: “Find all the people who are named ‘Titus’” <pre> In Graql: match $x isa person, has firstname $y; $y val is “Titus”;
by 6d6b73 9y ago
This is why we can't have nice things:
“Find all the people who are named ‘Titus’”
<pre>
In Graql:
match $x isa person, has firstname $y; $y val is “Titus”;
In ASP:
match(Person) :- isa(Person, person), has(Person, firstname, "Titus").
#show match/1.
</pre>
Why can't it simply be
"FIND people NAME 'Titus' "
?
- Karrot_Kream 9y agoRemember that you can build goals on top of these. This is just informative for people who already model things in logic programming languages. Nothing stopping you from creating your own goal: `first_name(Name, Person) :- person(Person), person_name(Person, first, Name).` and calling it `first_name("Titus", P).`
- protomyth 9y agoI get the feeling a nice DSL or macros (Lisp not C style) would help. Also, I miss Symantec Q&A.
- muydeemer 9y agoYou can omit the optional value variable and have: match $x isa person, has firstname 'Titus';
- DonbunEf7 9y agoI am neither Byrd nor Friedman but I will try my best. The short answer is that it doesn't compose very well, especially when doing relational programming. Let's say that `people` is a record of some sort, and not a relation. That is, when we extract people, we get records of data which we can manipulate, and not a set of functions which let us relate the records to each other. Now, imagine a logical query which has the following steps: exists p :Person guard p.name == "Titus" exists gp :Person ? isGrandParent(gp, p) call scan(gp) return gp, p How is this actually going to be executed? Well, you can imagine that first, we'll fetch a Person record, then we'll check if the name is "Titus", and then we'll fetch his grandparents, calling `scan` on each one. (No, I don't know why we would scan grandparents. Here in the USA, we actually let them skip the scanners.) Seems easy, right? What if we make a tiny swap... exists p :Person exists gp :Person ? isGrandParent(gp, p) call scan(gp) guard p.name == "Titus" return gp, p Crap, this isn't the same program. We'll scan every grandparent, even ones without grandkids named Titus. Relational operators are supposed to commute, but these ones don't commute! What happened? Well, accessing a runtime-computed non-relational fact, like the name of a person here, is an impure operation. It doesn't compose. So! What's the right answer? We have to express the person<->name connection as a relation rather than a record: exists p :Person ? personHasName(p, "Titus") exists gp :Person ? isGrandParent(gp, p) call somePred(gp) return gp, p Byrd's thesis glosses over this point and simply says that we should already have internalized the impurity of `project` or other projection operators. Edit: I fixed some typos. Also, this paper [0] on my paperstack has Friedman as a co-author and purports to solve this problem in a generic way by adding pure symbolic constraints to miniKanren. [0] https://arxiv.org/pdf/1701.00633.pdf https://arxiv.org/pdf/1701.00633.pdf
- NotAUsername 9y agoGreat point about compositionality, thank you!