Mercury 14.01

объяснил почему на фразу «что никто не гарантирует, что решения будут находиться в каком-то определённом порядке».

Дык надо нормально объяснять: «есть несколько семантик, наличие строгой гарантируется, что по умолчанию - не известно» и «что никто не гарантирует ...» - совершенно различные вещи, ибо делать акцент на умолчания компилятора по сравнению с требованиями языка неправильно, али нет?

но он не определен если не

Вот и мной было замечено, что из описания модуля не следует принципиальная неупорядоченность. Из наличия опций mmc она следует. Этого было достаточно, для чего цитировался solutions - не совсем поднятно.

то наверное лучше не брать отдельные фразы, а прочитать полностью и до конца:

Угомонись: не «читать», а «цитировать». Цитировал, чтобы показать наличие строгой, про умолчания даже заметил, что «не определены». Мною был искажен смысл?

По мне, так разница между

Причем тут это вообще? Третий раз: «про умолчания» никто не настаивал.

Дык надо нормально объяснять

В своем объяснении про «в каком-то определённом порядке» я вроде нормально и объяснил, с упоминанием ключиков, или нет? А затем вылезло «но все не так плохо, как вы с proud_anon-ом напели» непонятно к чему.

ибо делать акцент на умолчания компилятора по сравнению с требованиями языка неправильно

Требования языка это одно, а умолчания несколько другое, не? Эти ключики, насколько я помню, нужны для обхода багов mmc с некоторыми версиями gcc и некоторых других ситуаций. С точки зрения логического языка, эти ключики - не нужны костыли. Да и в мануале где-то тоже написано, что ключики есть, но лучше их не использовать дабы не ломать оптимизацию.

для чего цитировался solutions - не совсем поднятно

Разговор шел про «решения будут находиться в каком-то определённом порядке», по содержанию модуля видно, что какого-то определенного порядка нет, иначе не было бы solutions и unsorted_solutions.

Мною был искажен смысл?

Нет. Но по мне, цитируя данный кусок, надо обратить внимание, что это поведение «по умолчанию» не используется, по причинам о которых написал выше.

В своем объяснении про «в каком-то определённом порядке» я вроде нормально и объяснил

По моему вопросу было очевидно, что семантика mercury мне знакома слабо, лучше объяснять руководствуясь не только контекстом компилятора, но и _языка_. Нафига запутывать?

А затем вылезло «но все не так плохо, как вы с proud_anon-ом напели» непонятно к чему.

Все понятно, ибо _категоричность_ заявления плохо соотносилась с _однобокостью_: для меня гарантия, что можно получить решения в порядке дизъюктов существенна.

_вылезло_

Не огрызайся. Впрочем, ладно, огрызайся)

иначе не было бы solutions и unsorted_solutions

Вот-вот, поэтому я и писал: «Как из конткеста понять, что _unsorted_ подразумевает принципиально _unordered_». Пример: find выводит unsorted, но порядок не unordered (в данной директории вызовы будут давать одинаковый результат).

unsorted

То есть мало ли какой он внутренний sort делает. Из контеста сразу не понял. Только и всего.

Нафига запутывать?

Дык, никто вроде не запутывал =) Лично я, да наверное отношусь к этой возможности однобоко, потому что считаю, что эта возможность костыли =) для обхода багов и отладки, потому как у меня необходимости в ее использовании не было. Да и сами авторы там же пишут (и не только там):

Programmers who care more about ease of programming and portability than about efficiency can use the strict sequential semantics.

Пример: find выводит unsorted, но порядок не unordered (в данной директории вызовы будут давать одинаковый результат).

Чет не распарсил. Для меня ordered значит, что у каждого из элементов есть определенная позиция (как в сях set/unordered_set). В случае с find, к примеру, если он возвращает list и не использует сортировки, результат всегда ordered, но не обязательно sorted и поэтому вызовы на одной и той же директории могут выдавать разный результат, т.к. унификация [«dir1», «dir2»] и [«dir2», «dir1»] пройдет безуспешно.

авторы там же пишут (и не только там)

Где там про обход багов? С каких пор «обходом багов» занимается стандарт языка: какой компилятор хочет обходит - добавляет возможность.

ordered, но не обязательно sorted
поэтому вызовы на одной и той же директории

емнип, он выводит в том порядке, в котором иноды записаны в «файле-директории». По-крайней мере в таком смысле приводил: получение файлов в соотвествии с внутренним порядком, если нужен внешний - то sort.

Типа термин ordered - хранения, sorted - для отдачи? Ну тогда даже в таком понимании наличие unsorted_solutions, не говорит о том, что нет внутреннего ordered-представления.

емнип, он выводит в том порядке, в котором иноды записаны в «файле-директории».

Пример с 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» и поэтому засунули эти ключи в стандарт, и расписали последовательность миниальной перестановки и выполнения кода, так сказать, позаботились о несчастных программистах.

С радостью приму дополнения к этим пунктам =), но чет не вижу других вариантов зачем нужна такая возможность.

встроенным каррированием

Одного карринга мало. Нужен еще как минимум оператор композиции, тогда можно писать в безточечном стиле.