Re: Boundary conditions

On 15/11/2013, at 2:01 AM, Bengbers wrote:
> Why on _earth_ do you put spaces after left parentheses?

> 
> *I remember having read somewhere that this was the preferred coding-style
> in Prolog...*

This has never been the case.  I _think_ Ivan Bratko did this in
his book, but he was alone in this.  The last time I could count,
I had used over 300 programming languages (yes, really) and lopsided
spacing wasn't preferred style in *any* of them.

There is a paper by Covington and some other people about Prolog style...
> 
> The word "_list" here doesn't add any information either.
> 
> *Both 'Control' and 'Check' are the results of setof/3 so they contain no
> duplicates. 'Unique' is the list that results from subtracting 'control'
> from 'Check'.*

Like I say, the word "list" doesn't add any information here.
If they are the results of setof/3, they are *sets* (no duplicates,
which is useful to know) and they are *ordered sets* (in @< order,
which is additional useful information) and that means you can use
ord_subtract/3.
> 
>> 
>> 2 uniques_list( Control, [H|Tail], Accu, Unique) :-
>>   \+member( H, Control), Accu2=[H|Accu], uniques_list( Control, Tail,
>> Accu2, Unique).
> 
> Why have you switched from the name "Check" to the name "Tail"?
> This is confusing?
> "Accu" is a state of Unique;
> the standard naming convention here would be
> 
>        uniques_list(Control, [X|Check], Unique0, Unique) :-
>            \+ member(X, Control),
>            !, % you need this so the next clause isn't tried.
>            Unique0 = [X|Unique1],
>            uniques_list(Control, Check, Unique1, Unique).
> 
> *The theory (and Alan Baljeu) say that the cut is needed here but even
> without the !, my procedure now works fine. Is this just plain luck?*

What do you mean "works fine"?

There is a big difference between "I type in a query at the command
line and the first answer that comes back is right" and "when
failed back into, *every* answer is right."  Alan wasn't talking
about the case when the first clause failed but about the case
when the first clause succeeded. 

> Oh whoops.  I see that for no apparent reason you are reversing
> the list Check as you filter it to Unique.  Why bother?
> 
> *The order is not relevant to me.*

No, it _is_ relevant to you, you just didn't realise.
Being in sorted order means you can use an existing linear-time
predicate to do what you want.  You can do other set operations
efficiently on the results as well.  Scramble or even just
reverse the order, and you can't.

> Apart from the corrections you also give a lot of suggestions for the coding
> style. For better readability, I prefer using names instead of characters
> but that is just a naming convention.

I don't know what you are talking about.  Where did I suggest
_not_ using a name?  Can you possibly be referring to the long-
established and extremely helpful convention that a group of
variables that refer to successive states of the same "thing"
are named
	Thing0 Thing1 Thing2 .... Thing?

Those are names!  You need something that makes it clear what the
order of the things is, and there is no convention you can make
up which will be as instantly recognisable and processable as
the natural numbers.  The numbers are *not* arbitrary labels,
which appears to be the thought behind your dismissal of them as
"characters".

> On internet I see that there exist a lot of coding styleguides for Prolog.
> Which coding convention is preferred by most of the serious
> Prolog-programmers?

There's only one I am aware of which has any claim to being more
than one person's private taste, and that's the one by Covington
et al -- I have the honour to be one of the authors.  What's
particularly useful is that we _didn't_ always reach consensus
-- other style guides often offer the illusion of consensus when
there is none -- and gave _reasons_.  Sometimes there's more than
one alternative with good reasons for it.