Coding Guidelines for Prolog · HackerPapers discussions

Coding Guidelines for Prolog — mentioned by YeGoblynQueenne

Sun, 13 Oct 2024 20:20:14 GMT

>> Right now this seems to have all the downsides of programming exclusively with "magic strings", and I haven't been able to find any cure for it or even seen this problem discussed elsewhere. The cure is to not try to program with "magic strings". You don't need to, and if you really want to, then you should try to understand what exactly it is that you're doing, and do it right. Specifically, what you call "magic strings" are what we call "functions" in First Order Logic, and that Prolog calls compound terms, like carring_rock(robot(R)) which is in fact two compound terms, nested. Prolog…

Paper and discussion history. A mention is not an endorsement.

Coding Guidelines for Prolog — HN submission

Sat, 23 Sep 2023 12:20:42 GMT

Coding Guidelines for Prolog (2011)

126 points; 14 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Coding Guidelines for Prolog — mentioned by YeGoblynQueenne

Wed, 13 Sep 2023 10:28:40 GMT

Do I have any hints? Oh dear. The advice in this technical report is sound: Coding Guidelines for Prolog https://arxiv.org/abs/0911.2899 It goes over some style matters but also makes more practical recommendations about using the language for best results. I have followed those guidelines in the last few years, often before reading the book, and they have generally served me well. My own, very personal advice is to avoid the dynamic database as if it was the plague. To clarify, the "dynamic database" refers to the use of assert/1, retract/1 and friends to add to, and remove clauses from the…

Paper and discussion history. A mention is not an endorsement.

Coding Guidelines for Prolog — mentioned by YeGoblynQueenne

Sun, 11 Apr 2021 23:16:57 GMT

Nice, but this: should_isolate(Person) :- has_symptoms(Person); tested_positive(Person); ( lives_with_others(Person), format(atom(LivingWithPeople), 'anyone living with ~w', Person), ( has_symptoms(LivingWithPeople); tested_positive(LivingWithPeople) ) ); ( in_bubble(Person), format(atom(BubblePeople), 'anyone in ~w\'s bubble', Person), ( ( has_symptoms(BubblePeople), contact_with_symptomatic_bubble_member(Person) ); ( tested_positive(BubblePeople), contact_with_positive_bubble_member(Person) ) ) ); contacted_by_test_and_trace(Person); ( arrived_from_abroad_recently(Person), \+…

Paper and discussion history. A mention is not an endorsement.

Coding Guidelines for Prolog — HN submission

Sat, 28 Nov 2020 13:56:29 GMT

Coding Guidelines for Prolog (2009)

7 points; 2 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Coding Guidelines for Prolog — mentioned by YeGoblynQueenne

Sun, 09 Oct 2016 10:55:24 GMT

>> getting Prolog to do cool things quickly involved knowing precisely where to put cut operators, and that was basically black magic. But it's been a while. To add to tom_mellior's much upvoatable reply, I find that the cut is much less painful if you keep your predicates small and mind separation of concerns, as you should anyway. A good recommendation about when to use the cut operator is "as soon as undesired nondeterminism happens". With short and to-the-point predicates this is much easier to do. Finally- the Prolog community has a term for two types of cut, the "green cut" and "red…

Paper and discussion history. A mention is not an endorsement.

Coding Guidelines for Prolog — HN submission

Wed, 30 Dec 2009 20:47:38 GMT

Coding Guidelines for Prolog

7 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.