🚀 go-pugleaf

In article <548@ecrcvax.UUCP>, micha@ecrcvax.UUCP (Micha Meier) writes:
> 	The problem with Prolog is that any of the term(s in an if->then;else)
>	can be a conjunction, disjunction or if-then-else.  What about
>       (   (   C1 ->
>               B1
>           ;
>               B2
>           ) ->
>           (   C2 ->
>               B3
>           ;
>               B4
>           ),
>           B5
> 	;   B6,
>           B7
> 	)
Algol 60, Algol 68, Lisp, Pop, Bourne shell, C shell, ML, ... have
exactly the same problem.  There's nothing special about Prolog in this
respect.  The answer is that it isn't a problem to have another if in a
then-part or else-part, and that programmers who care about readability
don't put ifs in if-parts.  The big lesson for Prolog programmers is
"don't be scared of introducing new predicates". Programmers who do not
care about readability will find obfuscatory ways despite standards.
(The famous "Indian Hills style sheet" for C has led to some of the most
unreadable C code it has ever been my misfortune to try to read.)

I basically agree with Meier's concern for readability.  But I think the
layout of the Prolog code as such is not the most important aspect.  It
is easy to write a reformatter (the editor I'm using to write this has one).
You can fix what is there, the trouble is what _isn't_ there.  I have
recently had occasion to look at two people's programs.  One of them
I repeatedly misunderstood because it was doing some very tricky things
in its control flow and had essentially no comments.  The other I still
do not understand because it is doing non-obvious things with its data
structures and has essentially no comments.

Rules of thumb for comments:
(1) Describe all major data structures.
(2) Comment every control trick.