Пролог вызывает неправильное правило. Не правильно отступает

Сохраняйте logical-purity, используя встроенные предикаты same_length/2, length/2 и append/3!

replace_at(I,X,Xs0,Xs2) :-
   same_length(Xs0,Xs2),
   append(Prefix,[_|Xs1],Xs0),
   length([_|Prefix],I),
   append(Prefix,[X|Xs1],Xs2).

Во-первых, давайте запустим пример запроса, который @magus использовал в предыдущем ответе на этот вопрос:

?- replace_at(3,0,[1,2,3,4,5,6],Xs).
Xs = [1,2,0,4,5,6] ;
false.

Работает ли это, когда элементы списка создаются позже?

?- replace_at(3,0,[A,B,C,D,E,F],Xs), A=1,B=2,C=3,D=4,E=5,F=6.
A = 1, B = 2, C = 3, D = 4, E = 5, F = 6, Xs = [1,2,0,4,5,6] ;
false.

Да! Что, если индекс представляет собой не конкретное целое число, а несвязанную логическую переменную? Это работает?

?- replace_at(I,x,[_,_,_,_,_],Ys).
I = 1, Ys = [ x,_B,_C,_D,_E] ;
I = 2, Ys = [_A, x,_C,_D,_E] ;
I = 3, Ys = [_A,_B, x,_D,_E] ;
I = 4, Ys = [_A,_B,_C, x,_E] ;
I = 5, Ys = [_A,_B,_C,_D, x] ;
false.

Да! С монотонным кодом мы получаем логически обоснованные ответы даже на очень общие запросы.

Я подозреваю, что вы неправильно понимаете направление, в котором будет происходить откат.

Первое «базовое» правило будет пробоваться первым для любого вызова replaceAtIndex/4. Если это не удается из-за неунифицируемости вызова с «головой» первого правила, то механизм Пролога возвращается ко второму правилу. [Ошибка объединения может произойти из-за того, что первый аргумент (индекс) отличен от 1, или из-за того, что третий аргумент не является непустым списком.]

Откат никогда не идет в другом направлении. Если второе правило опробовано и терпит неудачу, вызов терпит неудачу.

Конечно, все усложняется рекурсивным определением. Успех применения второго правила влечет за собой новый вызов replaceAtIndex/4, который, насколько это касается механизма Prolog, должен начать попытки выполнить эту цель, начиная с первого правила.

Я бы предложил добавить сокращение к первому правилу, так как по построению второе правило никогда не будет успешным, если первое правило будет успешным. Но это всего лишь вопрос эффективности... зачем оставлять открытой точку выбора, которая никогда не приведет к каким-либо дальнейшим решениям?

replaceAtIndex(1, _element, [_|_tail], [_element|_tail]) :- !.

Добавлено: я подтвердил, что ваш код работает в Amzi! Пролог с таким вызовом:

?- replaceAtIndex(3, 0, [1,2,3,4,5,6], L).

L = [1, 2, 0, 4, 5, 6] ;
no
?- 

Но, конечно, вы также видите успех, когда код вызывается в автономном/интерпретируемом режиме.

Поэтому я должен подозревать, что передаваемый аргумент «индекс» не является целым числом, а скорее числом с плавающей запятой. Целое число 1 не будет объединяться с числом с плавающей запятой 1.0, даже если они математически равны.

Вы можете использовать предикат is_integer/1, чтобы проверить это в Amzi! Пролог. Функцию integer(X) можно использовать для преобразования вещественного числа 1,0 в целое число 1 путем усечения (несуществующей) дробной части.

Попробуйте _index_in_list установить на 1. Разве тогда не будет вызвано первое правило?

Конечно, причина, по которой вызывается второе правило, если ваше _index_in_list равно 111, заключается в том, что 111 больше, чем 1? Первое правило касается только 1 - как говорит первый параметр.

Когда я заменяю _index_in_list константой 111, все работает.

Какая? Вы имеете в виду, что вызывается первое правило? Как же так, первый параметр 1.