Исправление gloomdemon, (текущая версия) :
емнип, он выводит в том порядке, в котором иноды записаны в «файле-директории».
Пример с find немного не удачный =). find по факту детерминированный поэтому там вариантов не будет никаких. Просто мы разговаривали о функциях milti и поэтому я написал пример выше как если бы find был multi и выбирал не из инод, т.е.:
:- pred find(string::out) is multi.
find("dir1").
find("dir2").
find("dir3").
и есть, к примеру, два варианта вызова
1) solutions(find, Dirs) и Dirs всегда будет списком [«dir1», «dir2», «dir3»]
2)
do_while(find, check, [], Dirs)
:- pred check(string::in, bool:out, list(string)::in, list(string)::out) is det.
check(Dir, Next, Dirs0, Dirs) :- Next = yes, Dirs = [Dir | Dirs0].
Типа термин ordered - хранения, sorted - для отдачи?
Хм, чет опять не то. Еще раз, есть list, он же всегда ordered, потому что элементы в list'е находятся в определенном порядке, у них есть позиция. Но в случае с предикатом типа multi и unsorted_solutions у тебя в списке элементы будут находится в том порядке в каком тебе возвращает решения этот самый предикат, а предикат типа multi может их возвращать в любом порядке. Поэтому unsorted_solutions и имеет тип cc_multi, потому как вариантов комбинации решений может быть много [«dir1», «dir3», «dir2»], [«dir2», «dir3», «dir1»] и т.д. (это все разные списки), но выберут и вернут только один из этих вариантов. А просто solutions собирает все решения предиката multi, сортирует, убирает дубликаты и возвращает один и тот же результат, т.е. что-то типа [«dir1», «dir2», «dir3»].
Где там про обход багов?
Прям там и нет. Но надо просто рассылку разработчиков читать переодически, вот к примеру, хотя бы http://www.mercurylang.org/list-archives/developers/2001-March/011835.html, http://www.mercurylang.org/list-archives/developers/2007-January/014604.html .
Для меня (и я так понимаю для разработчиков тоже) есть две ситуации зачем в логическом языке запрещать во _всех_ конъюнкциях и дизъюнкциях менять местами независимые выражения:
1) ураганный ***** код в стиле D \= 0, R = Num / D, когда нужно что-бы во всем модуле ни в коем случае не поменялось ничего местами;
2) баг или особенности (изменения) оптимизатора какого нибудь компилятора mercury с наложением на ошибку в коде, поэтому авторы и пишут «ease of programming and portability» и поэтому засунули эти ключи в стандарт, и расписали последовательность миниальной перестановки и выполнения кода, так сказать, позаботились о несчастных программистах.
С радостью приму дополнения к этим пунктам =), но чет не вижу других вариантов зачем нужна такая возможность.
Исправление gloomdemon, :
емнип, он выводит в том порядке, в котором иноды записаны в «файле-директории».
Пример с find немного не удачный =). find по факту детерминированный поэтому там вариантов не будет никаких. Просто мы разговаривали о функциях milti и поэтому я написал пример выше как если бы find был multi и выбирал не из инод, т.е.:
:- pred find(string::out) is multi.
find("dir1").
find("dir2").
find("dir3").
и есть, к примеру, два варианта вызова
1) solutions(find, Dirs) и Dirs всегда будет списком [«dir1», «dir2», «dir3»]
2)
do_while(find, check, [], Dirs)
:- pred check(string::in, bool:out, list(string)::in, list(string)::out) is det.
check(Dir, Next, Dirs0, Dirs) :- Next = yes, Dirs = [Dir | Dirs0].
Типа термин ordered - хранения, sorted - для отдачи?
Хм, чет опять не то. Еще раз, есть list, он же всегда ordered, потому что элементы в list'е находятся в определенном порядке, у них есть позиция. Но в случае с предикатом типа multi и unsorted_solutions у тебя в списке элементы будут находится в том порядке в каком тебе возвращает решения этот самый предикат, а предикат типа multi может их возвращать в любом порядке. Поэтому unsorted_solutions и имеет тип cc_multi, потому как вариантов комбинации решений может быть много [«dir1», «dir3», «dir2»], [«dir2», «dir3», «dir1»] и т.д. (это все разные списки), но выберут и вернут только один из этих вариантов. А просто solutions собирает все решения предиката multi, сортирует, убирает дубликаты и возвращает один и тот же результат, т.е. что-то типа [«dir1», «dir2», «dir3»].
Где там про обход багов?
Прям там и нет. Но надо просто рассылку разработчиков читать переодически, вот к примеру, хотя бы http://www.mercurylang.org/list-archives/developers/2001-March/011835.html, http://www.mercurylang.org/list-archives/developers/2007-January/014604.html .
Для меня (и я так понимаю для разработчиков тоже) есть две ситуации зачем в логическом языке запрещать во _всех_ конъюнкциях и дизъюнкциях менять местами независимые выражения:
1) ураганный ***** код в стиле D \= 0, R = Num / D, когда нужно что-бы во всем модуле ни в коем случае не поменялось ничего местами;
2) баг или особенности (изменения) оптимизатора какого нибудь компилятора mercury с наложением на ошибку в коде, поэтому авторы и пишут «ease of programming and portability» и поэтому засунули эти ключи в стандарт, и расписали последовательность миниальной перестановки и выполнения кода, так сказать, позаботились о несчастных программистах.
С радостью приму дополнения к этим пунктам =)
Исправление gloomdemon, :
емнип, он выводит в том порядке, в котором иноды записаны в «файле-директории».
Пример с find немного не удачный =). find по факту детерминированный поэтому там вариантов не будет никаких. Просто мы разговаривали о функциях milti и поэтому я написал пример выше как если бы find был multi и выбирал не из инод, т.е.:
:- pred find(string::out) is multi.
find("dir1").
find("dir2").
find("dir3").
и есть, к примеру, два варианта вызова
1) solutions(find, Dirs) и Dirs всегда будет списком [«dir1», «dir2», «dir3»]
2)
do_while(find, check, [], Dirs)
:- pred check(string::in, bool:out, list(string)::in, list(string)::out) is det.
check(Dir, Next, Dirs0, Dirs) :- Next = yes, Dirs = [Dir | Dirs0].
Типа термин ordered - хранения, sorted - для отдачи?
Хм, чет опять не то. Еще раз, есть list, он же всегда ordered, потому что элементы в list'е находятся в определенном порядке, у них есть позиция. Но в случае с предикатом типа multi и unsorted_solutions у тебя в списке элементы будут находится в том порядке в каком тебе возвращает решения этот самый предикат, а предикат типа multi может их возвращать в любом порядке. Поэтому unsorted_solutions и имеет тип cc_multi, потому как вариантов комбинации решений может быть много [«dir1», «dir3», «dir2»], [«dir2», «dir3», «dir1»] и т.д. (это все разные списки), но выберут и вернут только один из этих вариантов. А просто solutions собирает все решения предиката multi, сортирует, убирает дубликаты и возвращает один и тот же результат, т.е. что-то типа [«dir1», «dir2», «dir3»].
Где там про обход багов?
Прям там и нет. Но надо просто рассылку разработчиков читать переодически, вот к примеру, хотя бы http://www.mercurylang.org/list-archives/developers/2001-March/011835.html, http://www.mercurylang.org/list-archives/developers/2007-January/014604.html .
Для меня (и я так понимаю для разработчиков тоже) есть две ситуации зачем в логическом языке запрещать во _всех_ конъюнкциях и дизъюнкциях менять местами независимые выражения:
1) ураганный ***** код в стиле D \= 0, R = Num / D, когда нужно что-бы во всем модуле ни в коем случае не поменялось ничего местами;
2) баг или особенности (изменения) оптимизатора какого нибудь компилятора mercury с наложением на ошибку в коде, поэтому авторы и пишут «ease of programming and portability» и поэтому засунули эти ключи в стандарт и расписали последовательность миниальной перестановки и выполнения кода, так сказать, позаботились о несчастных программистах.
С радостью приму дополнения к этим пунктам =)
Исходная версия gloomdemon, :
емнип, он выводит в том порядке, в котором иноды записаны в «файле-директории».
Пример с find немного не удачный =). find по факту детерминированный поэтому там вариантов не будет никаких. Просто мы разговаривали о функциях milti и поэтому я написал пример выше как если бы find был multi и выбирал не из инод, т.е.:
:- pred find(string::out) is multi.
find("dir1").
find("dir2").
find("dir3").
и есть, к примеру, два варианта вызова
1) solutions(find, Dirs) и Dirs всегда будет списком [«dir1», «dir2», «dir3»]
2)
do_while(pred(out) is multi, pred(in, out, in, out) is det, in, out) pred do_while(pred(T), pred(T, bool, T2, T2), T2, T2).
do_while(find, check, [], Dirs)
:- pred check(string::in, bool:out, list(string)::in, list(string)::out) is det.
check(Dir, Next, Dirs0, Dirs) :- Next = yes, Dirs = [Dir | Dirs0].
Типа термин ordered - хранения, sorted - для отдачи?
Хм, чет опять не то. Еще раз, есть list, он же всегда ordered, потому что элементы в list'е находятся в определенном порядке, у них есть позиция. Но в случае с предикатом типа multi и unsorted_solutions у тебя в списке элементы будут находится в том порядке в каком тебе возвращает решения этот самый предикат, а предикат типа multi может их возвращать в любом порядке. Поэтому unsorted_solutions и имеет тип cc_multi, потому как вариантов комбинации решений может быть много [«dir1», «dir3», «dir2»], [«dir2», «dir3», «dir1»] и т.д. (это все разные списки), но выберут и вернут только один из этих вариантов. А просто solutions собирает все решения предиката multi, сортирует, убирает дубликаты и возвращает один и тот же результат, т.е. что-то типа [«dir1», «dir2», «dir3»].
Где там про обход багов?
Прям там и нет. Но надо просто рассылку разработчиков читать переодически, вот к примеру, хотя бы http://www.mercurylang.org/list-archives/developers/2001-March/011835.html, http://www.mercurylang.org/list-archives/developers/2007-January/014604.html .
Для меня (и я так понимаю для разработчиков тоже) есть две ситуации зачем в логическом языке запрещать во _всех_ конъюнкциях и дизъюнкциях менять местами независимые выражения:
1) ураганный ***** код в стиле D \= 0, R = Num / D, когда нужно что-бы во всем модуле ни в коем случае не поменялось ничего местами;
2) баг или особенности (изменения) оптимизатора какого нибудь компилятора mercury с наложением на ошибку в коде, поэтому авторы и пишут «ease of programming and portability» и поэтому засунули эти ключи в стандарт и расписали последовательность миниальной перестановки и выполнения кода, так сказать, позаботились о несчастных программистах.
С радостью приму дополнения к этим пунктам =)