14 files changed, 674 insertions, 20 deletions
diff --git a/prolog/problems/lists/conc_3/en.py b/prolog/problems/lists/conc_3/en.py
index e25ae32..be32b7d 100644
--- a/prolog/problems/lists/conc_3/en.py
+++ b/prolog/problems/lists/conc_3/en.py
@@ -10,4 +10,113 @@ description = '''\
   X = [1,2,3].
 </pre>'''
 
-hint = {}
+plan = ['''\
+<p><img src="[%@resource plan.svg%]" /></p>
+''', '''\
+<p>Let's start with an easy question. What do I get if I concatenate an empty list and a list <code>L2</code>?</p>
+''', '''\
+<p>Now, assume that the first list has exactly one element. Let's temporarily take it out which leaves us
+with an empty list. But wait! Isn't this situation now similar to the one we dealt with before? Of course, we just
+reduced the problem into a smaller one (by one element smaller). Let recursion solve this smaller problem. Just don't
+forget to expand the recursion's result with the element you have taken out at the beginning...</p>
+''', '''\
+<p>Declarative/logic reasoning: Assume the first list <code>L1</code> has head <code>H</code> and tail
+<code>T</code>. If the recursive result of concatenating <code>T</code> and <code>L2</code> is some list
+<code>L3</code>, and if we add element <code>H</code> at the beginning of list <code>L3</code>, what do we get?
+A concatenation of <code>L1</code> and <code>L2</code>!</p>
+''']
+
+hint = {
+    'eq_instead_of_equ': '''\
+<p>The operator <code>==</code> is "stricter" than operator <code>=</code> in the sense that
+for the latter it is enough to be able to make the two operands equal (unification). Perhaps by using <code>=</code>
+you can make the predicate <code>conc/3</code> more general (e.g. able to work with output arguments becoming inputs).</p>
+<p>Of course, you can also solve the exercise without explicit use of either of these two operators, just
+remember that unification is implicitly performed with the predicate's arguments (head of clause).</p>
+''',
+
+    'eq_instead_of_equ_markup': '''\
+<p>Perhaps the operator for unification (=) would be better?</p>
+''',
+
+    'base_case': '''\
+<p>Did you think of a base case? What is the simplest possible case?
+What's the answer if, for example, the first list is empty? (Just the first list should be empty,
+the second one can be arbitrary.)</p>
+''',
+
+    'base_case_arbitrary': '''\
+<p>How can the result of concatenating two lists be an arbitrary list (a variable without an assigned value)?</p>
+<p>If your base case is similar to <code>conc([], L, _)</code>,
+then you should rethink it: what is the result of the concatenation, what do you return as the result?
+The base case <em>always</em> fully specifies the result, usually there are no unknowns (<code>_</code>
+or variables without assigned values) in what is being returned as the result.</p>
+''',
+
+    'predicate_always_false': '''\
+<p>It seems your predicate is <emph>always</emph> "false". Did you give it the correct name,
+or is it perhaps misspelled?</p>
+<p>If the name is correct, check whether something else is misspelled, perhaps there is a full stop instead of
+a comma or vice versa, or maybe you typed a variable name in lowercase?</p>
+<p>It is, of course, also possible that your conditions are too restrictive, or even impossible to satisfy
+(as would be, for example, the condition that an empty list <code>[]</code> is equal to a list with
+exactly three elements <code>[A,B,C]</code>, or something similarly impossible).</p>
+''',
+
+    'timeout': '''\
+<p>Is there an infinite recursion at work here? How will it ever stop?</p>
+<p>Or perhaps is there a missing, faulty, or simply incompatible (with the general recursive case) base case?
+Are you maybe reducing the first list, but your base case stops with an empty second list (or vice versa)?</p>
+''',
+
+    'second_list_iteration': '''\
+<p>It seems you're processing (reducing) the second list. The mechanism at work is correct, however,
+the final ordering of the elements is not. It's better to process the first list in this way and
+leave the second one as is.</p>
+<p>There's another reason to process the first list: in this way the solution of this essential exercise
+will be the same for everyone, and we'll be able to use <code>conc/3</code> in a standardised way. This
+will be very important later on.</p>
+''',
+
+    'insertion_into_second_list': '''
+<p>Is your recursive call of the form <code>conc(T, [H|L2], ...)</code>?
+Don't insert the first list's head into the second list as this will result in the wrong ordering
+of the elements. Let the recursion alone take care of concatenating the first list's tail
+<code>T</code> with the second list <code>L2</code>, and then, when returning the complete result,
+add the first list's head <code>H</code> into its proper place.</p>
+''',
+
+    'two_heads': '''\
+<p>Do you really need two list heads? Are you trying to reduce both lists? This is not a good idea, it is
+difficult to solve the exercise in this way. Rather simply reduce the first list only, and leave the
+other list as is.</p>
+''',
+
+    'two_heads_markup': '''\
+<p>Do you really need two list heads?</p>
+''',
+
+    'forcing_result_onto_recursion': '''
+<p>Don't force the result onto recursion, don't tell it what it should return. Just assume it will do its job.
+If this assumption is correct, then the rule will work for a larger case.</p>
+<p>Is your recursive call of the form <code>conc(T, L2, [H|...])</code>? This forces the recursive call to
+<em>return</em> the head at the start of the concatenated list. But it doesn't know of this head, because you just
+took it away! Inserting the head into the result, returned by the recursive call, is your job. To put it shortly,
+insert <code>H</code> outside of the recursive call.</p>
+''',
+
+    'final_hint': '''\
+<p>Predicate <code>conc/3</code> will be useful for much more than just concatenating two lists.
+Among other things it can be used "in the other direction" -- for dividing a list into two parts. Try the
+following queries:</p>
+<p><code>?- conc(L1, L2, [a,b,c,d]).</code></p>
+<p><code>?- conc([X,Y], L2, [a,b,c,d,e,f]).</code></p>
+<p>Did you notice that the second query returned the first two elements from the list <code>[a,b,c,d,e,f]</code>?</p>
+<p>Furthermore, <code>conc/3</code> is useful to search for patterns in a list, e.g.:</p>
+<p><code>?- conc(_, [X,X|_], [a,b,c,c,d,e,f,f,g,h,h]).</code></p>
+<p>Right, this query finds all possibilities where two identical elements appear one after the other in a list
+(pattern X,X). Basically the query said that "there are some elements (possibly zero) in front, then follow two
+identical elements, and then again some elements (possibly zero) at the end."</p>
+<p>There are many other usages of <code>conc/3</code>, you will discover them along the way.</p>
+''',
+}
diff --git a/prolog/problems/lists/conc_3/sl.py b/prolog/problems/lists/conc_3/sl.py
index be2590e..5b0a639 100644
--- a/prolog/problems/lists/conc_3/sl.py
+++ b/prolog/problems/lists/conc_3/sl.py
@@ -92,8 +92,8 @@ res težko prišel do pravilne rešitve. Raje zmanjšuj samo prvi seznam in pust
     'forcing_result_onto_recursion': '''
 <p>Ne vsiljuj rekurziji kaj naj vrne, prepusti se ji. To je tisti del, ko narediš predpostavko,
 če je ta izpolnjena, potem bo tvoje pravilo delovalo za večji primer.</p>
-<p>Je tvoj rekurzivni klic oblike <code>conc(T, L2 [H|...])</code>? S tem vsiljuješ rekurziji
-da mora <emph>vrniti</emph> tudi glavo, ki si jo prej že dal začasno stran. Glavo moraš na koncu na primerno mesto
+<p>Je tvoj rekurzivni klic oblike <code>conc(T, L2, [H|...])</code>? S tem vsiljuješ rekurziji
+da mora <em>vrniti</em> tudi glavo, ki si jo prej že dal začasno stran. Glavo moraš na koncu na primerno mesto
 vstaviti ti. Skratka, glavo <code>H</code> dodaj izven rekurzivnega klica.</p>
 ''',
 
@@ -105,9 +105,9 @@ Med drugim je uporaben "v obratni smeri" za delitev seznama na dva dela, poskusi
 <p>Si opazil, da je drugo vprašanje v bistvu vrnilo prva dva elementa iz seznama <code>[a,b,c,d,e,f]</code>?</p>
 <p>Nadalje je <code>conc/3</code> uporaben za iskanje vzorcev v seznamu, npr. takole:</p>
 <p><code>?- conc(_, [X,X|_], [a,b,c,c,d,e,f,f,g,h,h]).</code></p>
-<p>Tako je, to vprašanje najde vse možnosti, kjer se dva elementa ponovita drug za drugim v seznamu (vzorec X,X).
+<p>Tako je, to vprašanje najde vse možnosti, kjer se dva enaka elementa ponovita drug za drugim v seznamu (vzorec X,X).
 V bistvu smo rekli "nekaj poljubnih elementov (lahko tudi nič) je spredaj, potem sta dva enaka, potem pa spet nekaj
-poljubnih elementov (lahko nič) zadaj."
-Še veliko drugih koristi bo od <code>conc/3</code>, jih boš že še sproti spoznal.</p>
+poljubnih elementov (lahko nič) zadaj."</p>
+<p>Še veliko drugih koristi bo od <code>conc/3</code>, jih boš že še sproti spoznal.</p>
 ''',
 }
diff --git a/prolog/problems/lists/del_3/en.py b/prolog/problems/lists/del_3/en.py
index 99f87ca..d6e1e30 100644
--- a/prolog/problems/lists/del_3/en.py
+++ b/prolog/problems/lists/del_3/en.py
@@ -1,5 +1,5 @@
 name = 'del/3'
-slug = 'delete an element from list'
+slug = 'delete element from list'
 
 description = '''\
 <p><code>del(X, L1, L2)</code>: the list <code>L2</code> is obtained from <code>L1</code> by deleting element <code>X</code>.</p>
@@ -15,4 +15,93 @@ description = '''\
   X = 3, L = [1,2].
 </pre>'''
 
-hint = {}
+plan = ['''
+<p style="text-align: center;">
+    <img style="display: inline-block; width: 40%; border-right: 1px solid lightgray;" src="[%@resource plan_a.svg%]" />
+    <img style="display: inline-block; width: 40%;" src="[%@resource plan_b.svg%]" />
+</p>
+<p>This exercise is very similar to the exercise <code>memb/2</code>, except that this time we also delete
+the element we are looking for. Where in the list can element <code>X</code> be hiding?
+Remember that a list has two parts: head and tail. Therefore there are two possibilies!</p>
+''', '''\
+<p>What is the simplest option? Perhaps deleting the first element?</p>
+''', '''\
+<p>How do I delete from the list's tail? Just divide the list into its head and tail, recursively (as
+the problem is one element smaller now) delete from the tail, and at the end don't forget about the
+head previously taken away.</p>
+''', '''\
+<p>Recursive step: if we assume <code>NewTail</code> is the tail with element <code>X</code> already deleted,
+then <code>[H|NewTail]</code> is the whole list with element <code>X</code> deleted.</p>
+''']
+
+hint = {
+    'eq_instead_of_equ': '''\
+<p>The operator <code>==</code> is "stricter" than operator <code>=</code> in the sense that
+for the latter it is enough to be able to make the two operands equal (unification). Perhaps by using <code>=</code>
+you can make the predicate <code>del/3</code> more general (e.g. able to work with output arguments becoming inputs).</p>
+<p>Of course, you can also solve the exercise without explicit use of either of these two operators, just
+remember that unification is implicitly performed with the predicate's arguments (head of clause).</p>
+''',
+
+    'eq_instead_of_equ_markup': '''\
+<p>Perhaps the operator for unification (=) would be better?</p>
+''',
+
+    'base_case': '''\
+<p><img src="[%@resource base_case.svg%]" /></p>
+<p>Did you think of a base case? Where in the list is it the easiest to delete an element?</p>
+''',
+
+    'recursive_case': '''\
+<p>The base case is ok. However, what about the general recursive case?</p>
+''',
+
+    'predicate_always_false': '''\
+<p>It seems your predicate is <emph>always</emph> "false". Did you give it the correct name,
+or is it perhaps misspelled?</p>
+<p>If the name is correct, check whether something else is misspelled, perhaps there is a full stop instead of
+a comma or vice versa, or maybe you typed a variable name in lowercase?</p>
+<p>It is, of course, also possible that your conditions are too restrictive, or even impossible to satisfy
+(as would be, for example, the condition that an empty list <code>[]</code> is equal to a list with
+exactly three elements <code>[A,B,C]</code>,
+or something similarly impossible).</p>
+''',
+
+    'timeout': '''\
+<p>Is there an infinite recursion at work here? How will it ever stop?</p>
+<p>Or perhaps is there a missing, faulty, or simply incompatible (with the general recursive case) base case?</p>
+''',
+
+    'del_from_empty_list_success': '''\
+<p>You can't delete an element from an empty list!</p>
+<p>If I delete an element from an empty list, this doesn't result in an empty list or anything else, but it
+simply shouldn't succeed. You don't even have to include a rule for this as prolog by default acts like that.
+You know how prolog loves to say "no"! :)</p>
+<p>If that is your base case, rethink it! Where in the list is it the easiest to delete an element?</p>
+''',
+
+    'lost_heads': '''\
+<p><img src="[%@resource lost_heads.svg%]" /></p>
+<p>The element has been successfully deleted, but all the others before it got deleted too, right?
+Did you forget to put the head back at the front of the list after returning from recursion?</p>
+<p>Try asking the following query:</p>
+<p><code>?- del(d, [a,b,c,d,e,f,g], L).</code></p>
+''',
+
+    'leading_heads_all_x': '''\
+<p><img src="[%@resource leading_heads_all_x.svg%]" /></p>
+<p>Did you forget (copy/paste?) and used <code>[X|T]</code> instead of the more general <code>[H|T]</code>
+in the recursive case?</p>
+<p>Of the following two queries one works and the other doesn't.</p>
+<p><code>?- del(d, [d,d,d,d,e,f,g], L).</code></p>
+<p><code>?- del(d, [a,b,c,d,e,f,g], L).</code></p>
+''',
+
+    'final_hint': '''\
+<p>Interesting tidbit. Inserting and deleting an element into/from the list are opposite operations.
+Just by playing around with the arguments you can solve <code>del/3</code> using <code>insert/3</code>.</p>
+<p>Logically the following holds: deleting element <code>X</code> from list <code>BigList</code> resulting
+in list <code>SmallList</code> is the same as <em>inserting</em> element <code>X</code>
+into list <code>SmallList</code> to get list <code>BigList</code> as a result. ;)</p>
+''',
+}
diff --git a/prolog/problems/lists/del_3/sl.py b/prolog/problems/lists/del_3/sl.py
index feee5e4..17df017 100644
--- a/prolog/problems/lists/del_3/sl.py
+++ b/prolog/problems/lists/del_3/sl.py
@@ -97,7 +97,7 @@ Si pozabil dati glavo nazaj na začetek seznama, ko se vračaš iz rekurzije?</p
 <p>Zanimivost: operaciji vstavljanja in brisanja iz seznama sta si ravno nasprotni. Če se malce poigraš z
 argumenti, lahko <code>del/3</code> rešiš kar z <code>insert/3</code>.</p>
 <p>Logično velja naslednje: če zbrišem <code>X</code> iz seznama <code>BigList</code> in dobim kot rezultat
-seznam <code>SmallList</code> je isto kot če <emph>vstavim</emph> <code>X</code> v seznam <code>SmallList</code> in dobim
+seznam <code>SmallList</code> je isto kot če <em>vstavim</em> <code>X</code> v seznam <code>SmallList</code> in dobim
 kot rezultat seznam <code>BigList</code>. ;)</p>
 ''',
 }
diff --git a/prolog/problems/lists/divide_3/en.py b/prolog/problems/lists/divide_3/en.py
index f4cfa82..f47a51b 100644
--- a/prolog/problems/lists/divide_3/en.py
+++ b/prolog/problems/lists/divide_3/en.py
@@ -1,5 +1,5 @@
 name = 'divide/3'
-slug = 'split a list into parts of roughly equal length'
+slug = 'split a list into two parts of roughly equal length'
 
 description = '''\
 <p><code>divide(L, L1, L2)</code>: the list <code>L1</code> contains elements at odd positions in <code>L</code>, and the list <code>L2</code> contains the elements at even positions in <code>L</code>.</p>
@@ -10,4 +10,84 @@ description = '''\
   X = [a,c,e], Y = [b,d,f].
 </pre>'''
 
-hint = {}
+plan = ['''\
+<p><img src="[%@resource plan.svg%]" /></p>
+<p>You know... first, second, first, second, ...</p>
+''', '''\
+<p>Can you pick two heads from the list's beginning? The pattern is <code>[H1,H2|T]</code>.</p>
+''', '''\
+<p>You take two elements from the list's beginning, the rest is recursively split, and then you
+accordingly add those two elements into the recursion's result. By taking the two elements out,
+you reduce (simplify) the problem and thus enable the recursion.</p>
+''', '''\
+<p>If we assume the recursion splits the tail <code>T</code> into lists <code>L1</code> and <code>L2</code>,
+and upon returning the result we add <code>H1</code> at the start of <code>L1</code> and <code>H2</code>
+at the start of <code>L2</code>, then we get the split of the initial list of the form <code>[H1,H2|T]</code>
+into two approximately equal parts.</p>
+''']
+
+hint = {
+    'eq_instead_of_equ': '''\
+<p>The operator <code>==</code> is "stricter" than operator <code>=</code> in the sense that
+for the latter it is enough to be able to make the two operands equal (unification).</p>
+<p>Of course, you can also solve the exercise without explicit use of either of these two operators, just
+remember that unification is implicitly performed with the predicate's arguments (head of clause).</p>
+''',
+
+    'eq_instead_of_equ_markup': '''\
+<p>Perhaps the operator for unification (=) would be better?</p>
+''',
+
+    'base_case': '''\
+<p>Did you think of a base case? What's the simplest possible case? What if the list is empty?</p>
+''',
+
+    'base_case_arbitrary': '''\
+<p>How can the result of splitting a list be an arbitrary list(s) or an unassigned variable(s)?</p>
+<p>If your base case is reminiscent of <code>divide([], _, _)</code> or <code>divide([X], [X|_], ...)</code>,
+rethink it! What should be the result of splitting? The base case <em>always</em> fully specifies the result,
+usually there are no unknowns (<code>_</code> or variables without assigned values) in what is being
+returned as the result.</p>
+''',
+
+    'second_base_case_missing': '''\
+<p>The recursion doesn't always succeed. Are there perhaps two different cases how it could end? You know,
+odd and even ;) Do you need an extra base case? Try the following two queries; one will succeed, and the
+other will fail.</p>
+<p><code>?- divide([a,b,c], L1, L2).</code></p>
+<p><code>?- divide([a,b,c,d], L1, L2).</code></p>
+''',
+
+    'unsuccessful_conc_use': '''\
+<p>Are you using <code>conc/3</code>? This is probably not a good idea here as <code>conc/3</code>
+splits the list in "blocks" and not on an element-by-element level. Rather try without it.</p>
+''',
+
+    'forcing_result_onto_recursion': '''
+<p>Don't force the result onto recursion, don't tell it what it should return. Just let it be and
+assume it will do its job. If this assumption is correct, then the rule will work for a larger case.</p>
+<p>Is your recursive call of the form <code>divide(T, [H1|...], [H2|...])</code>? This forces the recursive call
+to also <em>return</em> both heads that it <em>doesn't know of</em> since you previously took them away.
+Adding those heads to the result, returned by the recursive call, is your job. To put it shortly,
+add elements <code>H1</code> and <code>H2</code> outside the recursive call.</p>
+''',
+
+    'recursive_case': '''\
+<p>The base cases are ok. However, what about the general recursive case?</p>
+''',
+
+    'predicate_always_false': '''\
+<p>It seems your predicate is <emph>always</emph> "false". Did you give it the correct name,
+or is it perhaps misspelled?</p>
+<p>If the name is correct, check whether something else is misspelled, perhaps there is a full stop instead of
+a comma or vice versa, or maybe you typed a variable name in lowercase?</p>
+<p>It is, of course, also possible that your conditions are too restrictive, or even impossible to satisfy
+(as would be, for example, the condition that an empty list <code>[]</code> is equal to a list with
+exactly three elements <code>[A,B,C]</code>, or something similarly impossible).</p>
+''',
+
+    'timeout': '''\
+<p>Is there an infinite recursion at work here? How will it ever stop?</p>
+<p>Or perhaps is there a missing, faulty, or simply incompatible (with the general recursive case) base case?</p>
+''',
+}
diff --git a/prolog/problems/lists/dup_2/en.py b/prolog/problems/lists/dup_2/en.py
index 3639683..e944f74 100644
--- a/prolog/problems/lists/dup_2/en.py
+++ b/prolog/problems/lists/dup_2/en.py
@@ -10,4 +10,77 @@ description = '''\
   X = [1,1,2,2,3,3].
 </pre>'''
 
-hint = {}
+plan = ['''
+<p><img src="[%@resource plan.svg%]" /></p>
+<p>This is an exercise in classic recursion. Let's be brave and assume that we already have
+a duplicated tail of the list. Then all we need to do is to duplicate the head (H becomes H, H) and
+add this at the start of the duplicated tail.</p>
+''', '''\
+<p>A base case must be elementary, right? What if the list doesn't contain any elements at all,
+what is the result in this case?</p>
+''', '''\
+<p>If we have a duplicated tail <code>DT</code> and put two heads <code>[H, H]</code> in front of it,
+then that is exactly the duplicated list.</p>
+<p>And how do we get the duplicated tail? Since the tail is smaller than the whole list,
+we can use recursion on it!</p>
+''']
+
+hint = {
+    'eq_instead_of_equ': '''\
+<p>The operator <code>==</code> is "stricter" than operator <code>=</code> in the sense that
+for the latter it is enough to be able to make the two operands equal (unification). Perhaps by using <code>=</code>
+you can make the predicate <code>dup/2</code> more general (e.g. able to work with output arguments becoming inputs).</p>
+<p>Of course, you can also solve the exercise without explicit use of either of these two operators, just
+remember that unification is implicitly performed with the predicate's arguments (head of clause).</p>
+''',
+
+    'eq_instead_of_equ_markup': '''\
+<p>Perhaps the operator for unification (=) would be better?</p>
+''',
+
+    'base_case_missing_[]': '''\
+<p>Your base case makes perfect sense, but it doesn't work for a very specific case: an empty list.
+Tweak it a little bit. However, don't write two base cases, because that will result in a new problem:
+the (albeit correct) solutions will all be repeated twice.</p>
+''',
+
+    'base_case_arbitrary': '''\
+<p>How can the result of duplicating an empty list be an arbitrary list or an unassigned variable?
+As the mathematicians would say: "Two times zero is zero and not just anything!"</p>
+<p>If your base case is <code>dup([], _).</code>, rethink it! What is the result of
+duplicating the elements of an empty list?</p>
+''',
+
+    'base_case': '''\
+<p>Did you think of a base case? Which list is the easiest to "duplicate"?</p>
+''',
+
+    'recursive_case': '''\
+<p>The base case is ok. However, what about the general recursive case?</p>
+''',
+
+    'predicate_always_false': '''\
+<p>It seems your predicate is <emph>always</emph> "false". Did you give it the correct name,
+or is it perhaps misspelled?</p>
+<p>If the name is correct, check whether something else is misspelled, perhaps there is a full stop instead of
+a comma or vice versa, or maybe you typed a variable name in lowercase?</p>
+<p>It is, of course, also possible that your conditions are too restrictive, or even impossible to satisfy
+(as would be, for example, the condition that an empty list <code>[]</code> is equal to a list with
+exactly three elements <code>[A,B,C]</code>,
+or something similarly impossible).</p>
+''',
+
+    'timeout': '''\
+<p>Is there an infinite recursion at work here? How will it ever stop?</p>
+<p>Or perhaps is there a missing, faulty, or simply incompatible (with the general recursive case) base case?</p>
+''',
+
+    'forcing_result_onto_recursion': '''
+<p>Don't force the result onto recursion, don't tell it what it should return. Just assume it will do its job.
+If this assumption is correct, then the rule will work for a larger case.</p>
+<p>Is your recursive call of the form <code>dup(T, [H,H|...])</code>? This forces the recursive call to
+<em>return</em> the duplicated head at the start of the list. But it doesn't know of this head, because you just
+took it away! Adding the duplicated head to the result, returned by the recursive call, is your job.
+To put it shortly, add the duplicated <code>H</code> outside of the recursive call.</p>
+''',
+}
diff --git a/prolog/problems/lists/dup_2/sl.py b/prolog/problems/lists/dup_2/sl.py
index 0358726..b1492c5 100644
--- a/prolog/problems/lists/dup_2/sl.py
+++ b/prolog/problems/lists/dup_2/sl.py
@@ -71,7 +71,7 @@ da je <code>X</code> hkrati starš in sestra od <code>Y</code> ali kaj podobno z
 <p>Ne vsiljuj rekurziji kaj naj vrne, prepusti se ji. To je tisti del, ko narediš predpostavko,
 če je ta izpolnjena, potem bo tvoje pravilo delovalo za večji primer.</p>
 <p>Je tvoj rekurzivni klic oblike <code>dup(T, [H,H|...])</code>? S tem vsiljuješ rekurziji
-da mora <emph>vrniti</emph> tudi podvojeno glavo. To moraš narediti ti z (obdelanim) rezultatom, ki ga rezurzija vrne.
+da mora <em>vrniti</em> tudi podvojeno glavo. To moraš narediti ti z (obdelanim) rezultatom, ki ga rezurzija vrne.
 Skratka, [H,H] dodaj izven rekurzivnega klica.</p>
 ''',
 }
diff --git a/prolog/problems/lists/insert_3/en.py b/prolog/problems/lists/insert_3/en.py
index 5553445..f0a3e4a 100644
--- a/prolog/problems/lists/insert_3/en.py
+++ b/prolog/problems/lists/insert_3/en.py
@@ -10,4 +10,84 @@ description = '''\
   L = [2,3,1].
 </pre>'''
 
-hint = {}
+plan = ['''
+<p><img src="[%@resource plan.svg%]" /></p>
+<p>Where in the list can we insert a new element <code>X</code>? Remember that a list has two parts: head and tail.
+That means there are two possibilies. That's right, only two -- but in the tail we can again insert either as its
+new head or into the tail of the tail. And so on. Recursion to the rescue!</p>
+''', '''\
+<p>What is the simplest option? Insert at the beginning!</p>
+''', '''\
+<p>How do I insert into the list's tail? Just divide the list into its head and tail, recursively (as
+the problem is one element smaller now) insert into the tail, and at the end don't forget about the
+head previously taken away.</p>
+''', '''\
+<p>Recursive step: if we assume <code>NewTail</code> is the tail with already inserted element <code>X</code>,
+then <code>[H|NewTail]</code> is the whole list with element <code>X</code> inserted.</p>
+''']
+
+hint = {
+    'eq_instead_of_equ': '''\
+<p>The operator <code>==</code> is "stricter" than operator <code>=</code> in the sense that
+for the latter it is enough to be able to make the two operands equal (unification). Perhaps by using <code>=</code>
+you can make the predicate <code>insert/3</code> more general (e.g. able to work with output arguments becoming inputs).
+This might come in handy later on!</p>
+<p>Of course, you can also solve the exercise without explicit use of either of these two operators, just
+remember that unification is implicitly performed with the predicate's arguments (head of clause).</p>
+''',
+
+    'eq_instead_of_equ_markup': '''\
+<p>Perhaps the operator for unification (=) would be better?</p>
+''',
+
+    'base_case': '''\
+<p><img src="[%@resource base_case.svg%]" /></p>
+<p>Did you think of a base case? In which place in the list is it the easiest to insert a new element?</p>
+''',
+
+    'recursive_case': '''\
+<p>The base case is ok. However, what about the general recursive case?</p>
+''',
+
+    'predicate_always_false': '''\
+<p>It seems your predicate is <emph>always</emph> "false". Did you give it the correct name,
+or is it perhaps misspelled?</p>
+<p>If the name is correct, check whether something else is misspelled, perhaps there is a full stop instead of
+a comma or vice versa, or maybe you typed a variable name in lowercase?</p>
+<p>It is, of course, also possible that your conditions are too restrictive, or even impossible to satisfy
+(as would be, for example, the condition that an empty list <code>[]</code> is equal to a list with
+exactly three elements <code>[A,B,C]</code>, or something similarly impossible).</p>
+''',
+
+    'timeout': '''\
+<p>Is there an infinite recursion at work here? How will it ever stop?</p>
+<p>Or perhaps is there a missing, faulty, or simply incompatible (with the general recursive case) base case?</p>
+''',
+
+    'ins_results_in_empty_list': '''\
+<p>How can the result of the insertion be an empty list?</p>
+<p>If that is your base case, rethink it! What is the result of the insertion?</p>
+''',
+
+    'ins_results_in_arbitrary_result': '''\
+<p>How can the result of the insertion be an arbitrary list or an unassigned variable?</p>
+<p>If that is your base case, rethink it! What is the result of the insertion?</p>
+''',
+
+    'lost_heads': '''\
+<p><img src="[%@resource lost_heads.svg%]" /></p>
+<p>The element has been successfully inserted, but all the others before it are lost, right?
+Did you forget to put the head back at the front of the list after returning from recursion?</p>
+<p>Try asking the following query and check <em>all</em> the solutions:</p>
+<p><code>?- insert(q, [a,b,c,d], L).</code></p>
+''',
+
+    'leading_heads_all_x': '''\
+<p><img src="[%@resource leading_heads_all_x.svg%]" /></p>
+<p>Did you forget (copy/paste?) and used <code>[X|T]</code> instead of the more general <code>[H|T]</code>
+in the recursive case?</p>
+<p>Of the following two queries one works and the other doesn't.</p>
+<p><code>?- insert(d, [d,d,d,d,e,f,g], L).</code></p>
+<p><code>?- insert(d, [a,b,c,d,e,f,g], L).</code></p>
+''',
+}
diff --git a/prolog/problems/lists/insert_3/sl.py b/prolog/problems/lists/insert_3/sl.py
index 17efb5b..7f62f7e 100644
--- a/prolog/problems/lists/insert_3/sl.py
+++ b/prolog/problems/lists/insert_3/sl.py
@@ -74,7 +74,7 @@ da je <code>X</code> hkrati starš in sestra od <code>Y</code> ali kaj podobno z
 <p><img src="[%@resource lost_heads.svg%]" /></p>
 <p>Element je vstavljen, ampak vsi pred njim so se pa izgubili, kajne?
 Si pozabil dati glavo nazaj na začetek seznama, ko se vračaš iz rekurzije?</p>
-<p>Poskusi postaviti naslednje vprašanje prologu in preglej <emph>vse</emph> rešitve:</p>
+<p>Poskusi postaviti naslednje vprašanje prologu in preglej <em>vse</em> rešitve:</p>
 <p><code>?- insert(q, [a,b,c,d], L).</code></p>
 ''',
 
diff --git a/prolog/problems/lists/last_elem_2/en.py b/prolog/problems/lists/last_elem_2/en.py
index 93c7c05..5eec3b8 100644
--- a/prolog/problems/lists/last_elem_2/en.py
+++ b/prolog/problems/lists/last_elem_2/en.py
@@ -10,4 +10,86 @@ description = '''\
   X = 1.
 </pre>'''
 
-hint = {}
+plan = ['''\
+<p>It's easy to access the first element in a list, but to get to the last element one needs to
+recursively go through the whole list.</p>
+''', '''\
+<p>The list can be divided into its head and tail, and the search can proceed with the tail.
+The problem is now smaller (the tail is shorter than the whole list), so we can use recursion.</p>
+''', '''\
+<p>If <code>X</code> is the last element of tail <code>T</code>, then <code>X</code> is also
+the last element of the whole list that looks like <code>[H|T]</code>.</p>
+''']
+
+hint = {
+    'eq_instead_of_equ': '''\
+<p>The operator <code>==</code> is "stricter" than operator <code>=</code> in the sense that
+for the latter it is enough to be able to make the two operands equal (unification). Perhaps by using <code>=</code>
+you can make the predicate <code>last_elem/2</code> more general (e.g. able to work with output arguments becoming inputs).</p>
+<p>Of course, you can also solve the exercise without explicit use of either of these two operators, just
+remember that unification is implicitly performed with the predicate's arguments (head of clause).</p>
+''',
+
+    'eq_instead_of_equ_markup': '''\
+<p>Perhaps the operator for unification (=) would be better?</p>
+''',
+
+    'base_case': '''\
+<p>Did you think of a base case? What's the simplest possible case? What if the list contains only one element?</p>
+''',
+
+    '[]_should_not_succeed': '''\
+<p>How did you succeed to find a last element in an empty list? You likely need a different base case.</p>
+''',
+
+    'list_returned': '''\
+<p>You are returning a list instead of an element.</p>
+''',
+
+    'clumsy_conc_use': '''\
+<p>Are you using <code>conc/3</code>? An interesting idea. Don't forget that the second list you're
+concatenating must be <em>of length one</em> if you want to achieve the desired effect.
+So a pattern of the form <code>[X]</code>, right?</p>
+''',
+
+    'unsuccessful_conc_use': '''\
+<p>Are you using <code>conc/3</code>? An interesting idea; it is possible to solve in this way.
+However, a bit of tweaking is still needed. Don't forget that <code>conc/3</code> has three arguments,
+and all three are lists. Think about what kind of a pattern do you need...</p>
+''',
+
+    'recursive_case': '''\
+<p>The base case is ok. However, what about the general recursive case?</p>
+''',
+
+    'predicate_always_false': '''\
+<p>It seems your predicate is <emph>always</emph> "false". Did you give it the correct name,
+or is it perhaps misspelled?</p>
+<p>If the name is correct, check whether something else is misspelled, perhaps there is a full stop instead of
+a comma or vice versa, or maybe you typed a variable name in lowercase?</p>
+<p>It is, of course, also possible that your conditions are too restrictive, or even impossible to satisfy
+(as would be, for example, the condition that an empty list <code>[]</code> is equal to a list with
+exactly three elements <code>[A,B,C]</code>,
+or something similarly impossible).</p>
+''',
+
+    'timeout': '''\
+<p>Is there an infinite recursion at work here? How will it ever stop?</p>
+<p>Or perhaps is there a missing, faulty, or simply incompatible (with the general recursive case) base case?</p>
+''',
+
+    'final_hint': '''\
+<p>Interesting fact: predicate <code>conc/3</code> can be used to search for patterns in lists. The last
+element in a list is also a kind of pattern. What happens if we concatenate an arbitrary list <code>_</code>
+and a list <em>of length one</em> (in this order)? A list of length one is of course written as
+<code>[Element]</code>.</p>
+<p>Try asking the following query:</p>
+<p><code>?- conc(_, [Element], [a,b,c,d,e,f,q]).</code></p>
+<p>So, can you now fetch the list's last element using <code>conc/3</code>? This will be very useful in
+further exercises. On the other hand, of course, accessing the last element of a list is still quite
+expensive, it's done in O(n) time. Therefore, if it's not important which element of a list is to be used,
+or where in a list a new element is to be added, always work with the head.</p>
+<p>And what does this query do? ;)</p>
+<p><code>?- conc([a,b,c], [q], L).</code></p>
+''',
+}
diff --git a/prolog/problems/lists/last_elem_2/sl.py b/prolog/problems/lists/last_elem_2/sl.py
index afba57a..961963c 100644
--- a/prolog/problems/lists/last_elem_2/sl.py
+++ b/prolog/problems/lists/last_elem_2/sl.py
@@ -47,7 +47,7 @@ implicitno že kar v argumentih predikata (glavi stavka).</p>
 
     'clumsy_conc_use': '''\
 <p>Uporabljaš <code>conc/3</code>? Zanimiva ideja. Ne pozabi, da mora drugi seznam, ki ga konkateniraš
-biti dolžine ena, če hočeš doseči to kar želiš. Torej vzorec oblike <code>[X]</code>, kajne?</p>
+biti <em>dolžine ena</em>, če hočeš doseči to kar želiš. Torej vzorec oblike <code>[X]</code>, kajne?</p>
 ''',
 
     'unsuccessful_conc_use': '''\
diff --git a/prolog/problems/lists/memb_2/en.py b/prolog/problems/lists/memb_2/en.py
index ae62825..681c18a 100644
--- a/prolog/problems/lists/memb_2/en.py
+++ b/prolog/problems/lists/memb_2/en.py
@@ -12,4 +12,70 @@ description = '''\
   X = 1.
 </pre>'''
 
-hint = {}
+plan = ['''\
+<p>Where can we find the searched for element <code>X</code>? Remember that the list has two parts: the head and
+the tail. Therefore, there are two possibilies! ;)</p>
+''', '''\
+<p><img src="[%@resource base_case.svg%]" /></p>
+<p>In prolog we can understand a list like a queue of people waiting for a bus. The driver only sees
+the first person in the queue, the others are hidden in the list's tail. So the element <code>X</code>
+can either be at the start of the queue or...</p>
+''', '''\
+<p>It's easy to look at ("search for") the head of the list. But how do we search the tail? Simply,
+we remove the first element and repeat the search with the smaller list (tail). If <code>[H|T]</code>
+is our whole list, then <code>T</code> is this same list without the first element.
+Since the new list (tail) is smaller, we reduced the problem and thus facilitated the use of recursion.</p>
+''']
+
+hint = {
+    'eq_instead_of_equ': '''\
+<p>The operator <code>==</code> is "stricter" than operator <code>=</code> in the sense that
+for the latter it is enough to be able to make the two operands equal (unification). Perhaps by using <code>=</code>
+you can make the predicate <code>memb/2</code> more general (e.g. able to work with output arguments becoming inputs).</p>
+<p>Of course, you can also solve the exercise without explicit use of either of these two operators, just
+remember that unification is implicitly performed with the predicate's arguments (head of clause).</p>
+''',
+
+    'eq_instead_of_equ_markup': '''\
+<p>Perhaps the operator for unification (=) would be better?</p>
+''',
+
+    'base_case': '''\
+<p><img src="[%@resource base_case.svg%]" /></p>
+<p>Did you think of a base case? What is the simplest possible case if the element is present in the list?
+Which element in the list is the easiest to access?</p>
+''',
+
+    'recursive_case': '''\
+<p>The base case is ok. However, what about the general recursive case?</p>
+''',
+
+    'predicate_always_false': '''\
+<p>It seems your predicate is <emph>always</emph> "false". Did you give it the correct name,
+or is it perhaps misspelled?</p>
+<p>If the name is correct, check whether something else is misspelled, perhaps there is a full stop instead of
+a comma or vice versa, or maybe you typed a variable name in lowercase?</p>
+<p>It is, of course, also possible that your conditions are too restrictive, or even impossible to satisfy
+(as would be, for example, the condition that an empty list <code>[]</code> is equal to a list with
+exactly three elements <code>[A,B,C]</code>,
+or something similarly impossible).</p>
+''',
+
+    'timeout': '''\
+<p>Is there an infinite recursion at work here? How will it ever stop?</p>
+<p>Or perhaps is there a missing, faulty, or simply incompatible (with the general recursive case) base case?</p>
+''',
+
+    'final_hint': '''\
+<p>Predicate <code>memb/2</code> is useful for much more than just checking whether a list contains
+a given element or not. Actually, most of the time, it's used in "a different direction" as
+"return some element <code>X</code> from list <code>L</code>". In fact you've just written yourself
+a generator of elements from the list.</p>
+<p>Try the following query:</p>
+<p><code>?- memb(Coin, [1,2,5,10,20,50,100,200]).</code></p>
+<p>or this one:</p>
+<p><code>?- memb(Operator, [+, -, *, /]).</code></p>
+<p>Can you form a query to ask prolog how do we get a sum of 30 cents with exactly three coins?
+The operator <code>=:=</code> is used to check for arithmetic equality. How many solutions are there? ;)</p>
+''',
+}
diff --git a/prolog/problems/lists/permute_2/en.py b/prolog/problems/lists/permute_2/en.py
index 201d8d6..ba20d67 100644
--- a/prolog/problems/lists/permute_2/en.py
+++ b/prolog/problems/lists/permute_2/en.py
@@ -13,4 +13,79 @@ description = '''\
   L = [3,2,1].
 </pre>'''
 
-hint = {}
+plan = ['''\
+<p><img src="[%@resource plan.svg%]" /></p>
+<p>Try recursively constructing one possibility, but leave prolog its freedom. It will then return
+all the possibilities by itself.</p>
+''', '''\
+<p>There are several options, one goes like this: if I take away the head, this reduces the problem and I can
+leave it to recursion, and at the end I put the head back. Where do I put the head? I insert it in
+<em>all</em> possible places, one solution at a time.</p>
+''', '''\
+<p>If I assume the recursion permutes the tail <code>T</code> into the "permutated tail"
+<code>PT</code> and then I insert head <code>H</code> somewhere into <code>PT</code>, then I will get
+some permutation of the initial list <code>[H|T]</code>.</p>
+''']
+
+hint = {
+    'eq_instead_of_equ': '''\
+<p>The operator <code>==</code> is "stricter" than operator <code>=</code> in the sense that
+for the latter it is enough to be able to make the two operands equal (unification).</p>
+<p>Of course, you can also solve the exercise without explicit use of either of these two operators, just
+remember that unification is implicitly performed with the predicate's arguments (head of clause).</p>
+''',
+
+    'eq_instead_of_equ_markup': '''\
+<p>Perhaps the operator for unification (=) would be better?</p>
+''',
+
+    'base_case': '''\
+<p>Did you think of a base case? What's the most elementary case? What if the list is empty?</p>
+''',
+
+    'base_case_arbitrary': '''\
+<p>How can the result of permutating a list be an arbitrary list or an unassigned variable?</p>
+<p>If your base case is reminiscent of <code>permute([], _)</code>, rethink it!
+What should be the result of permutating a list?
+The base case <em>always</em> fully specifies the result, usually there are no unknowns (<code>_</code>
+or variables without assigned values) in what is being returned as the result.</p>
+''',
+
+    'unsuccessful_conc_use': '''\
+<p>Are you using <code>conc/3</code>? It's probably not so useful to solve this exercise,
+but the solution to some other previous exercise might be what is required.</p>
+''',
+
+    'forcing_result_onto_recursion': '''
+<p>Don't force the result onto recursion, don't tell it what it should return. Just let it be and
+assume it will do its job. If this assumption is correct, then the rule will work for a larger case.</p>
+<p>Is your recursive call of the form <code>permute(T, [H|...])</code>? This forces the recursive call to
+also <em>return</em> the head <code>H</code> which it <em>doesn't know of</em> since you previously took it away.
+Inserting the head into the result, returned by the recursive call, is your job. To put it shortly,
+insert <code>H</code> outside of the recursive call.</p>
+''',
+
+    'recursive_case': '''\
+<p>The base case is ok. However, what about the general recursive case?</p>
+''',
+
+    'no_insert_or_delete': '''\
+<p>The base case is ok. However, what about the general recursive case? Perhaps it's a good idea
+to reuse some previous exercise?</p>
+''',
+
+    'predicate_always_false': '''\
+<p>It seems your predicate is <emph>always</emph> "false". Did you give it the correct name,
+or is it perhaps misspelled?</p>
+<p>If the name is correct, check whether something else is misspelled, perhaps there is a full stop instead of
+a comma or vice versa, or maybe you typed a variable name in lowercase?</p>
+<p>It is, of course, also possible that your conditions are too restrictive, or even impossible to satisfy
+(as would be, for example, the condition that an empty list <code>[]</code> is equal to a list with
+exactly three elements <code>[A,B,C]</code>, or something similarly impossible).</p>
+''',
+
+    'timeout': '''\
+<p>Is there an infinite recursion at work here? How will it ever stop?</p>
+<p>Or perhaps is there a missing, faulty, or simply incompatible (with the general recursive case) base case?</p>
+''',
+}
diff --git a/prolog/problems/lists/permute_2/sl.py b/prolog/problems/lists/permute_2/sl.py
index 8cd11e9..ccf4cd7 100644
--- a/prolog/problems/lists/permute_2/sl.py
+++ b/prolog/problems/lists/permute_2/sl.py
@@ -59,7 +59,7 @@ rešena naloga.</p>
 <p>Ne vsiljuj rekurziji kaj naj vrne, prepusti se ji. To je tisti del, ko narediš predpostavko,
 če je ta izpolnjena, potem bo tvoje pravilo delovalo za večji primer.</p>
 <p>Je tvoj rekurzivni klic oblike <code>permute(T, [H|...])</code>? S tem vsiljuješ rekurziji
-da mora <emph>vrniti</emph> tudi glavo, ki je sploh ne pozna, ker si jo ravnokar vzel stran! To moraš
+da mora <em>vrniti</em> tudi glavo, ki je sploh ne pozna, ker si jo ravnokar vzel stran! To moraš
 narediti ti z rezultatom, ki ga rekurzija vrne. Skratka, element <code>H</code> dodaj izven rekurzivnega klica.</p>
 ''',