🚀 go-pugleaf

In article <532@swivax.UUCP>, anjo@swivax.UUCP (Anjo Anjewierden) writes:
:         assocation(Stack, Key, Val, absent) :-
:                 is_empty(Stack),
:                 !.
:         association(Stack, Key, Val, Result) :-
:                 pop_stack(Key1, Val1, Stack, Stack1),
:                 (   Key1 \== Key ->
:                     association(Stack1, Key, Val, Result)
:                 ;   Val1 = Val ->
:                     Result = present
:                 ;   Result = conflict
:                 ).
: 
: 	%  Human-readable program.
: 
: 	association( Stack,Key,Val,absent ) :-
: 		is_empty( Stack ), !.
: 	association( Stack,Key,Val,Result ) :-
: 		pop_stack( Key1,Val1,Stack,Stack1 ),
: 		assoc_test( Key,Key1,Val,Val1,Stack1,Result ).
: 
: 	assoc_test( Key,Key,Val,Val,_,present ) :- !.
: 	assoc_test( Key,Key,_,_,_,conflict ) :- !.
: 	assoc_test( Key,_,Val,_,Stack,Result ) :-
: 		association( Stack,Key,Val,Result ).
: 
: If we agree that these two programs are functionally equivalent,
: we can ask two questions:

To the best of my belief I am human, and I think *both* versions are
readable.  (Why would anyone who puts *extra* space with parentheses
leave out the space which normally follows commas in punctuation?
Jamming the arguments into one black blob -vs- separating them clearly
is a much bigger readability issue to me than if-then-else -vs- several
clauses.  But I repeat, both versions can be read.)

However, the two versions are *NOT* equivalent!  If we call
	association({...key->val...}, key, val, conflict)
the first version will fail (because key==key and val=val) but the
second version will succeed.  That is to say (assuming that is_empty/1
and pop_stack/4 cannot both succeed for the same instantiated Stack)
the first version is _steadfast_ and the second isn't.  They are not
identical for another reason:  the first version uses == for key
comparison, and the second uses = .

Which version is faster depends entirely on whether the Prolog implementor
in question has chosen to put some work into if-then-elses or not.  I may
tend to over-use if-then-elses these days, but I like their transparent
honesty.  The fact that the "obvious" code using if-then-else was
steadfast and the "obvious" code using cuts wasn't would be a good reason
to prefer if-then-elses even if they were slower.