<p>Lets look at your example. It is very simple, so we will imagine it being more complex.  However, it seems you take for granted that side effects are essential. Let me question that a bit:</p>
<p>In your example you have made a very interesting discovery: The names of all seasons are of same length. What an earth-shattering insight! But wait, is it really true?
The most straight-forward way to verify this, is:</p>
<pre>?- <b>season(S), atom_length(S,L).</b>
   S = spring, L = 6
;  S = summer, L = 6
;  S = autumn, L = 6
;  S = winter, L = 6.
</pre>
<p>No need for <code>findall/3</code>, no need for <code>write/1</code>.</p>
<p>For a larger number of answers, visual inspection is not practical.  Imagine 400 seasons. But we can verify this with:</p>
<pre>?- <b>season(S), atom_length(S,L), dif(L,6).</b>
   false.
</pre>
<p>So we now know for sure that there is no season of a different length.</p>
<p>That is my very first answer to your question:</p>
<blockquote>
<p>As long as you can, use the toplevel shell and not your own side effecting procedures! Stretch things a little bit further to avoid side-effects altogether. This is the best way to avoid failure driven loops right from the beginning.</p>
</blockquote>
<p>There are more reasons why sticking to the toplevel shell is a good idea:</p>
<ul>
<li><p>If your programs can be easily queried on the toplevel, it will be trivial to add test cases for them.</p>
</li>
<li><p>The toplevel shell is used by many other users and therefore is very well tested. Your own writing is often flawed and untested. Think of constraints. Think of writing floats. Will you use <code>write/1</code> for floats too? What is the right way to write floats such that they can be read back accurately? There <em>is</em> a way to do this in <a href="/questions/tagged/iso-prolog" class="post-tag" title="show questions tagged &#39;iso-prolog&#39;" rel="tag">iso-prolog</a>.  Here is the answer:</p>
</li>
</ul>
<blockquote class="spoiler">
<p> In ISO, <code>writeq/1,2</code>, <code>write_canonical/1,2</code>, <code>write_term/2,3</code> with option <code>quoted(true)</code> guarantee that floats can be read back accurately.  That is, they are the same w.r.t. <code>(==)/2</code></p>
</blockquote>
<ul>
<li><p>The toplevel shell shows you valid Prolog text.  In fact, the answer itself is a query! It can be pasted back into the toplevel - only to get back the very same answer.  In this manner you will learn the more exotic but unavoidable details of Prolog, like quoting, escaping and bracketing. It is practically impossible to learn the syntax otherwise, since Prolog parsers are often extremely permissive.</p>
</li>
<li><p>Your program will be most probably more accessible to declarative reasoning.</p>
</li>
</ul>
<p>Very likely, your two procedures <code>methodone</code> and <code>methodtwo</code> are incorrect: You forgot a newline after writing <code>Done</code>. So <code>methodone, methodone</code> contains a garbled line. How to test that easily?</p>
<p>But lets look a little bit further into your program. What is so typical for failure driven loops is that they start innocently as something doing &quot;only&quot; side effects but sooner or later they tend to attract more semantic parts as well.  In your case, <code>atom_length/2</code> is hidden down in the failure driven loop completely inaccessible to testing or reasoning.</p>
<h1>Efficiency considerations</h1>
<p>Prolog systems often implement failure by deallocating a stack.  Therefore, failure driven loops will not require a garbage collector. That's why people believe that failure driven loops are efficient. However, this is not necessarily the case.  For a goal like <code>findall(A, season(A), As)</code> every answer for <code>A</code> is copied into some space. This is a trivial operation for something like atoms but imagine a bigger term. Say:</p>
<pre>
blam([]).
blam([L|L]) :- blam(L).

bigterm(L) :- length(L,64), blam(L).
</pre>
<p>In many systems, <code>findall/3</code> or <code>assertz/1</code> for this big term will freeze the system.</p>
<p>Also, systems like SWI, YAP, SICStus do have quite sophisticated garbage collectors. And using fewer failure driven loops will help to improve those systems even further, since this creates a demand for <a href="http://arxiv.org/abs/1106.1311" rel="nofollow noreferrer">more sophisticated techniques</a>.</p>
What are the pros and cons of using manual list iteration vs recursion through fail
<p>I come up against this all the time, and I'm never sure which way to attack it. Below are two methods for processing some season facts.</p>

<p>What I'm trying to work out is whether to use method 1 or 2, and what are the pros and cons of each, especially large amounts of facts.</p>

<p><code>methodone</code> seems wasteful since the facts are available, why bother building a list of them (especially a large list). This must have memory implications too if the list is large enough ? And it doesn't take advantage of Prolog's natural backtracking feature. </p>

<p><code>methodtwo</code> takes advantage of backtracking to do the recursion for me, and I would guess would be much more memory efficient, but is it good programming practice generally to do this?  It's arguably uglier to follow, and might there be any other side effects?</p>

<p>One problem I can see is that each time <code>fail</code> is called, we lose the ability to pass anything back to the calling predicate, eg. if it was <code>methodtwo(SeasonResults)</code>, since we continually fail the predicate on purpose. So <code>methodtwo</code> would need to assert facts to store state.</p>

<p>Presumably(?) method 2 would be faster as it has no (large) list processing to do?  </p>

<p>I could imagine that if I had a list, then <code>methodone</code> would be the way to go.. or is that always true? Might it make sense in any conditions to assert the list to facts using <code>methodone</code> then process them using method two? Complete madness?</p>

<p>But then again, I read that asserting facts is a very 'expensive' business, so list handling might be the way to go, even for large lists?</p>

<p>Any thoughts? Or is it sometimes better to use one and not the other, depending on (what) situation?  eg. for memory optimisation, use method 2, including asserting facts and, for speed use method 1?</p>

<pre><code>season(spring).
season(summer).
season(autumn).
season(winter).

 % Season handling
showseason(Season) :-
    atom_length(Season, LenSeason),
    write('Season Length is '), write(LenSeason), nl.

% -------------------------------------------------------------
% Method 1 - Findall facts/iterate through the list and process each
%--------------------------------------------------------------
% Iterate manually through a season list
lenseason([]).
lenseason([Season|MoreSeasons]) :-
    showseason(Season),
    lenseason(MoreSeasons).


% Findall to build a list then iterate until all done
methodone :-
    findall(Season, season(Season), AllSeasons),
    lenseason(AllSeasons),
    write('Done').

% -------------------------------------------------------------
% Method 2 - Use fail to force recursion
%--------------------------------------------------------------
methodtwo :-
    % Get one season and show it
    season(Season),
    showseason(Season),

    % Force prolog to backtrack to find another season
    fail.

% No more seasons, we have finished
methodtwo :-
    write('Done').
</code></pre>