<div dir="ltr">Thanks for deeply considering my suggestion, Paul.<div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There is another reason I'd like to add in to the discussion, I apologise<br>
if someone has said this already. We have many predicates such as foldl,<br>
foldl2, foldl3 etc in the list module of the standard library. We also have<br>
map_corresponding and numerous other predicates, each predicate has a<br>
number of different modes. It can be painful when you need to use a<br>
predicate that fits one of these patterns in some ways, but doesn't fit the<br>
number of accumulators, number of output or input lists (map_corresponding)<br>
etc. This is particularly bad when the ADT is abstract (like maps, but<br>
unlike list) where you cannot write such a predicate without modifying the<br>
standard library.<br></blockquote><div><br></div><div>Yep, this is what Peter Schachte was getting at, I think.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think that the solution should be something smiliar to Matt's proposal<br>
(below) that can also work on integers. Peter Schachte's paper may also be<br>
useful but I've not read it, John's reference to Visual Prolog might also be<br>
useful. Additionally, one case where I've seen this done before was SISAL,<br>
a pure single assignment language that used loops that looked similar to<br>
imperative loops <a href="http://en.wikipedia.org/wiki/SISAL" target="_blank">http://en.wikipedia.org/wiki/SISAL</a>. Ultimately SISAL was<br>
not adopted by the programming community because Fortran programmers found<br>
it difficult to adjust to declrative programming. More about SISAL:<br>
<a href="http://www2.cmp.uea.ac.uk/~jrwg/Sisal/00.Contents.html" target="_blank">http://www2.cmp.uea.ac.uk/~jrwg/Sisal/00.Contents.html</a> Matt: is there<br>
something like this in Mars that we should also read?<br></blockquote><div><br></div><div>Mars loops are just simple while loops with the same semantics as Python. Nothing really special. (It isn't really relevant to Mercury because Mars local variables are re-assignable; in this sense Mars semantics are much closer to a conventional imperative language.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Fri, Jan 03, 2014 at 11:14:29AM +1100, Matt Giuca wrote:<br>
> I would propose a for loop syntax for Mercury which can be used something<br>
> like this:<br>
><br>
> :- pred print_key_values(assoc_list(string, string)::in, io::di, io::uo) is<br>
> det.<br>
> print_key_values(List, !IO) :-<br>
> for X-Y in List [!IO] (<br>
> io.write_string(X, !IO),<br>
> io.write_string(" = ", !IO),<br>
> io.write_string(Y, !IO),<br>
> <a href="http://io.nl" target="_blank">io.nl</a>(!IO)<br>
> ).<br>
><br>
> The features of this syntax are:<br>
><br>
</div>> 1. Clearly shows that X-Y is the elements of List, and that List is the<br>
> list being iterated over.<br>
> 2. Only need to specify the accumulators once (!IO), instead of<br>
<div class="im">> specifying them both in the predicate head and as separate arguments.<br>
</div>> 3. Works naturally with the !S state variable notation, not requiring<br>
<div class="im">> the user to break the illusion of S being a single variable and specify !.S<br>
> and !:S.<br>
</div>> 4. Does not allow the "invention" of new accumulator names; instead, you<br>
<div class="im">> are merely specifying existing variables from the outer scope (typically<br>
> state variables) that may be updated in the body of the loop.<br>
</div>> 5. Does not require the user to have to decide whether to use foldl,<br>
<div class="im">> foldl2, foldl3, etc. It works for any number of accumulator variables.<br>
</div>> 6. It keeps the idea that the user must explicitly specify which<br>
<div class="im">> variables can be updated by the loop body. You can't just go updating any<br>
> state variable in the outer scope, for example.<br>
><br>
<br>
</div>This seems good to me, I would like to extend it though so that:<br>
<br>
7. It can handle any number of input lists. (like map_corresponding).<br>
8. It can handle things other than lists (I have some ideas about how to<br>
do this that I can describe later).<br>
9. It can handle multiple outputs (not just accumoators) like list.map<br>
does.<br>
10. Guards can be added to support filtering.<br></blockquote><div><br></div><div>I would support all of these, as long as they can be added cleanly to the syntax (i.e., all of these features are optional and I don't need to provide, for example, a "returning" clause when I'm not using it for a map).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">SISAL was a pure language that had structures like this that were used for</span><br>
</div>
looping and such more often than recursion. This and your own work show<br>
that the imperative/declarative dichotomy really is a false one (yes, I<br>
deliberately paraphrased one of your titles).<br></blockquote><div><br></div><div>Thanks :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, because you, and I'm sure others, would have found such a feature<br>
useful in Mercury means that it is valuable. If there are good ideas whose<br>
effort to implement and maintain are worthwhile then there's no reason we<br>
should reject them.<br></blockquote><div><br></div><div>Julian's previous post suggests that something very similar to my suggestion was attempted thirteen years ago, and was abandoned largely for implementation reasons. If such a feature <i>is</i> going to add significant implementation overhead, then that is a reason to think twice about it. Not to say it should be abandoned again, but that the payoff has to be worth the effort. As I'm not a Mercury developer, I can't speak to the difficulty of implementing it, so I'll leave it to better minds to discuss.</div>
<div><br></div><div>Matt</div></div></div></div>