name = 'permute/2' slug = 'generate permutations of a list' description = '''\
permute(L1, L2)
: the list L2
is a permutation of the elements of the list L1
.
?- permute([1,2,3], L). L = [1,2,3] ; L = [1,3,2] ; L = [2,1,3] ; L = [2,3,1] ; L = [3,1,2] ; L = [3,2,1].''' plan = ['''\
Try recursively constructing one possibility, but leave prolog its freedom. It will then return all the possibilities by itself.
''', '''\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 all possible places, one solution at a time.
''', '''\If I assume the recursion permutes the tail T
into the "permutated tail"
PT
and then I insert head H
somewhere into PT
, then I will get
some permutation of the initial list [H|T]
.
The operator ==
is "stricter" than operator =
in the sense that
for the latter it is enough to be able to make the two operands equal (unification).
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).
''', 'eq_instead_of_equ_markup': '''\Perhaps the operator for unification (=) would be better?
''', 'base_case': '''\Did you think of a base case? What's the most elementary case? What if the list is empty?
''', 'base_case_arbitrary': '''\How can the result of permutating a list be an arbitrary list or an unassigned variable?
If your base case is reminiscent of permute([], _)
, rethink it!
What should be the result of permutating a list?
The base case always fully specifies the result, usually there are no unknowns (_
or variables without assigned values) in what is being returned as the result.
Are you using conc/3
? It's probably not so useful to solve this exercise,
but the solution to some other previous exercise might be what is required.
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.
Is your recursive call of the form permute(T, [H|...])
? This forces the recursive call to
also return the head H
which it doesn't know of 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 H
outside of the recursive call.
The base case is ok. However, what about the general recursive case?
''', 'no_insert_or_delete': '''\The base case is ok. However, what about the general recursive case? Perhaps it's a good idea to reuse some previous exercise?
''', 'predicate_always_false': '''\It seems your predicate is
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?
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 []
is equal to a list with
exactly three elements [A,B,C]
, or something similarly impossible).
Is there an infinite recursion at work here? How will it ever stop?
Or perhaps is there a missing, faulty, or simply incompatible (with the general recursive case) base case?
''', }