<div dir="ltr">>Actually, I would advise against doing this. The code of solutions/2 has to do<br><div>>something that cannot be done in pure Mercury: communicating information</div><div>>between different branches of a disjunction. It therefore has to use impure code,</div><div>>even though the interface it is implementing has a pure semantics. This works,</div><div>>but I wouldn't recommend the code to nonexperts.<br><br>>TL/DR: if you have no simple way to construct your list directly, then use</div><div>>the Mercury library's solutions/2, or one of the other predicates in the solutions</div><div>>module; do NOT try to roll your own.  </div><div><br></div><div>Thank you for the clarification on this. I am still learning. I'm starting to get a decent grasp of how the language works in a single solution context, but I'm still learning how the compiler handles nondet code.  One of my biggest points of confusion/frustration is how cc_multi and cc_nondet work exactly, the semantics of the comitted choice modes.  Do they work in terms of a greedy 'first result is good enough if called in a single solution context'?  I need to work on my understanding on how det code works with nondet code.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 2, 2018 at 3:16 PM Zoltan Somogyi <<a href="mailto:zoltan.somogyi@runbox.com">zoltan.somogyi@runbox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On Fri, 2 Nov 2018 15:04:15 -0400, Charlie McGee <<a href="mailto:c4cypher@gmail.com" target="_blank">c4cypher@gmail.com</a>> wrote:<br>
<br>
> >If you can construct a list of solutions directly, that will usually be<br>
> faster<br>
> >than using solutions/2, since the latter has nontrivial overhead. Whether<br>
> >it will be *measurably* faster depends on what fraction of the program's<br>
> >overall runtime this task takes, and on whether your direct method<br>
> >for construction of solutions requires a post-pass to sort the solutions,<br>
> >or to eliminate duplicates (two tasks that solutions/2 does for you,<br>
> >and which form part of its overheads).<br>
> <br>
> Building on Zoltan Somogyi's suggestion to construct your own list instead<br>
> of relying on solutions/2, if you want to get an idea of how to do that,<br>
> you can look on how the solutions library implements its calls by looking<br>
> through solutions.m<br>
> <<a href="https://github.com/Mercury-Language/mercury/blob/master/library/solutions.m" rel="noreferrer" target="_blank">https://github.com/Mercury-Language/mercury/blob/master/library/solutions.m</a>><br>
> in the library folder of the Mercury source code (The Mercury Lang github<br>
> repository is very useful for this).<br>
<br>
Actually, I would advise against doing this. The code of solutions/2 has to do<br>
something that cannot be done in pure Mercury: communicating information<br>
between different branches of a disjunction. It therefore has to use impure code,<br>
even though the interface it is implementing has a pure semantics. This works,<br>
but I wouldn't recommend the code to nonexperts.<br>
<br>
TL/DR: if you have no simple way to construct your list directly, then use<br>
the Mercury library's solutions/2, or one of the other predicates in the solutions<br>
module; do NOT try to roll your own.<br>
<br>
Zoltan.<br>
</blockquote></div>