3 ms·

I would phrase it like this: If you are using, in Prolog code, an atom of length greater than 1, then consider using a list of characters instead, especially if

by triska 4y ago

I would phrase it like this: If you are using, in Prolog code, an atom of length greater than 1, then consider using a list of characters instead, especially if you want to reason about the data itself within your program. If you use lists of characters throughout, then no conversion to or from longer atoms is needed. For example, in the sample queries you posted, instead of the atom abcd, consider using the list of characters "abcd" (i.e., [a,b,c,d]) instead, because such lists of characters can be readily described and analyzed with DCGs. In addition to this convenience, as a secondary concern, lists of characters provide an efficiency advantage, because they can be more transiently allocated on the Prolog heap instead of in the atom table, and are therefore immediately reclaimed on backtracking. Characters, i.e., 1-char atoms, are indeed a good use case of atoms. For anything longer, lists of characters are in many cases a better option: In addition to their being amenable to reasoning with DCGs and the mentioned efficiency advantage, they also allow partial instantiations, such as [a,b,c|Ls] and [a,B,c,d], a feature that atoms do not support. Hence, when using atoms, the code tends to become more moded, whereas lists of characters readily allow generalizations. Existing and upcoming Prolog implementation techniques allow a very compact internal representation of lists of characters as packed UTF-8 encoded sequences of bytes, and also a very efficient representation of each character as a single heap cell. Scryer Prolog and Trealla Prolog are the first Prolog systems that provide such an efficient internal representation of lists of characters, and are therefore already especially useful for efficient text processing.

YeGoblynQueenne 4y ago
>> I would phrase it like this: If you are using, in Prolog code, an atom of length greater than 1, then consider using a list of characters instead, especially if you want to reason about the data itself within your program. If you use lists of characters throughout, then no conversion to or from longer atoms is needed. That's a very good point and I agree. It reminds a little of how, in formal texts, constants are most often single characters, especially when we just want to refer to some abstract constant in which case we say "c" or "a" or "b" or "α", "β", "γ" and whatever (I do the latter because I have a Greek keyboard and it's easy). But there's a problem with that. In many cases in everyday Prolog programming it makes a lot of sense to represent constants by more than one character. For example, in the perennial family tree motivating example for ILP, you have (FOL) atoms like father(bob,alice) and mother(alice,dhalia) etc. That makes for a very natural notation- "bob" is clearly the name of a person. And then we end up with multi-character atoms that we might need to split or concatenate. Representing such constants as lists of characters would be cumbersome and unnatural- for example father([b,o,b],[a,l,i,c,e]), looks awful, even if it's actually very practical. That's partly what the double-quoted atoms are supposed to achieve, but father("bob", "alice") again introduces unnecessary visual clutter. Perhaps the standard should be for multi-character atoms (or, well, all atoms) to be expanded to lists of atoms by the interpreter by default (without having to double quote) so that you know that writing father(bob,alice) is exactly the same as writing father([b,o,b],[a,l,i,c,e]) and you can then do some list processing, e.g. starting with father(X,Y), then append(X,...) and so on. To be honest, I don't know much about how data are represented in memory in a Prolog engine- I think you know much more about all that, than me. So I can't imagine what the right answer is. A compact, efficient representation of lists of characters sounds useful, for sure.
- triska 4y ago
  In my experience, data in Prolog programs will look like alice, bob and dhalia only in very artificial examples or exercises. For example, I have never seen a person's name spelled bob, and spelled like this, it is rather unlikely to be the name of a person one would represent in a Prolog program. In Prolog programs that arise in practice, names are far more likely to look like "Alice", "King Solomon's Mines" and "La Grande Bellezza", and these names would need single-quotes or escape sequences for atoms too.
  - YeGoblynQueenne 4y ago
    I disagree! 'bob' is a fine identifier for an object in the domain of discourse and an excellent key to bind together disparate facts representing diverse information about the object. For example: person_name(bob, "Bob"). person_town(bob, "Bobberton"). person_occupation(bob, "Bobbie"). person_hobby(bob, "Bobbing"). And so on. And if there's multiple Bobs, 'bob1', 'bob2', 'bob3' etc, are also fine identifiers. You certainly don't want to have "King Solomon's Mine" as the first term in a fact. That's fine for user-level representation, but not so much as a system-level representation. 'place_name("King Solomon's Mine") would look downright awful during debugging, especially if it were expanded into a character list. (I use text debugging exclusively, so YMMV). Anyway that's how I write all my Prolog programs so it certainly arises in practice.
    - triska 4y ago
      Your example code now already uses lists of characters for names, and it is very readable. A good debugger will emit the exact same representation you are now using in the code, such as "Bobberton", "Bobbing" etc., and it will be very readable as well.

by triska 4y ago

YeGoblynQueenne 4y ago

>> I would phrase it like this: If you are using, in Prolog code, an atom of length greater than 1, then consider using a list of characters instead, especially if you want to reason about the data itself within your program. If you use lists of characters throughout, then no conversion to or from longer atoms is needed. That's a very good point and I agree. It reminds a little of how, in formal texts, constants are most often single characters, especially when we just want to refer to some abstract constant in which case we say "c" or "a" or "b" or "α", "β", "γ" and whatever (I do the latter because I have a Greek keyboard and it's easy). But there's a problem with that. In many cases in everyday Prolog programming it makes a lot of sense to represent constants by more than one character. For example, in the perennial family tree motivating example for ILP, you have (FOL) atoms like father(bob,alice) and mother(alice,dhalia) etc. That makes for a very natural notation- "bob" is clearly the name of a person. And then we end up with multi-character atoms that we might need to split or concatenate. Representing such constants as lists of characters would be cumbersome and unnatural- for example father([b,o,b],[a,l,i,c,e]), looks awful, even if it's actually very practical. That's partly what the double-quoted atoms are supposed to achieve, but father("bob", "alice") again introduces unnecessary visual clutter. Perhaps the standard should be for multi-character atoms (or, well, all atoms) to be expanded to lists of atoms by the interpreter by default (without having to double quote) so that you know that writing father(bob,alice) is exactly the same as writing father([b,o,b],[a,l,i,c,e]) and you can then do some list processing, e.g. starting with father(X,Y), then append(X,...) and so on. To be honest, I don't know much about how data are represented in memory in a Prolog engine- I think you know much more about all that, than me. So I can't imagine what the right answer is. A compact, efficient representation of lists of characters sounds useful, for sure.

triska 4y ago
In my experience, data in Prolog programs will look like alice, bob and dhalia only in very artificial examples or exercises. For example, I have never seen a person's name spelled bob, and spelled like this, it is rather unlikely to be the name of a person one would represent in a Prolog program. In Prolog programs that arise in practice, names are far more likely to look like "Alice", "King Solomon's Mines" and "La Grande Bellezza", and these names would need single-quotes or escape sequences for atoms too.
- YeGoblynQueenne 4y ago
  I disagree! 'bob' is a fine identifier for an object in the domain of discourse and an excellent key to bind together disparate facts representing diverse information about the object. For example: person_name(bob, "Bob"). person_town(bob, "Bobberton"). person_occupation(bob, "Bobbie"). person_hobby(bob, "Bobbing"). And so on. And if there's multiple Bobs, 'bob1', 'bob2', 'bob3' etc, are also fine identifiers. You certainly don't want to have "King Solomon's Mine" as the first term in a fact. That's fine for user-level representation, but not so much as a system-level representation. 'place_name("King Solomon's Mine") would look downright awful during debugging, especially if it were expanded into a character list. (I use text debugging exclusively, so YMMV). Anyway that's how I write all my Prolog programs so it certainly arises in practice.
  - triska 4y ago
    Your example code now already uses lists of characters for names, and it is very readable. A good debugger will emit the exact same representation you are now using in the code, such as "Bobberton", "Bobbing" etc., and it will be very readable as well.