<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>The reason is simply that partial functions in Scala are unary function, i.e. take only one argument, while reduce takes a binary function.</div><div><br></div><div>I already wrote in another mail why I think that the reduce example in the proposal is problematic, because it does argument splatting.</div><div><br></div><div>-Thorsten&nbsp;</div><div><br>Am 04.02.2016 um 22:57 schrieb Craig Cruden via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt;:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Off Topic a little.</div><div class=""><br class=""></div>I was playing around with the equivalent case - partial functions in Scala ….&nbsp;<div class=""><br class=""></div><div class="">I have known for whatever reason that they would not work within the Scala `reduce` but would work in other functions…. &nbsp;and it bugged me as to why it would work in most but not all (I was wondering if this was some weird implementation limitation). &nbsp;</div><div class=""><br class=""></div><div class="">As far as I can tell, there is a little difference that prevents it. &nbsp;Swift reduce is probably the same as Scala’s foldLeft. &nbsp;I had thought Scala’s reduce is a specialized form of fold but it is not the case.</div><div class=""><br class=""></div><div class="">The difference has to be that Scala’s `reduce` takes a “commutative monoid” — and case partial functions by their very nature [conditions on accumulator or value prevent it] are not commutative in nature — or at least not guaranteed to be so. &nbsp;</div><div class=""><br class=""></div><div class="">Scala’s fold is either left to right, or right to left. &nbsp;`reduce` on the other hand provides no guarantees because it may parallelize it [I am wondering if this is something in common with the concept of big data mapReduce].</div><div class=""><br class=""></div><div class="">——</div><div class=""><br class=""></div><div class="">Paul, I will look at updating the proposal to make that clear.&nbsp;</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 2016-02-05, at 4:17:03, Paul Ossenbruggen via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">I haven't thought of doing it this way This is why these reviews are great. I agree with Craig that, we would not allow commas before the colon. The proposal probably should be updated to make sure that is clear.&nbsp;</div><div class=""><br class="">Thanks&nbsp;</div><div class="">- Paul&nbsp;</div><div class=""><br class="">Sent from my iPhone</div><div class=""><br class="">On Feb 4, 2016, at 10:31 AM, Maximilian Hünenberger &lt;<a href="mailto:m.huenenberger@me.com" class="">m.huenenberger@me.com</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class="">I definitely see the point against dictionaries but I’m afraid of the actual pattern matching in "cases".</div><div class=""><br class=""></div><div class="">match(1) {</div><div class="">&nbsp; &nbsp; case 1, 3: 10</div><div class="">&nbsp; &nbsp; case 2, 4: 20</div><div class="">&nbsp; &nbsp; default: 30</div><div class="">}</div><div class=""><br class=""></div><div class="">// with "cases"</div><div class=""><br class=""></div><div class=""><div class="">match(1) { cases</div><div class="">&nbsp; &nbsp; 1, 3: 10,</div><div class="">&nbsp; &nbsp; 2, 4: 20,</div><div class="">&nbsp; &nbsp; default: 30</div><div class="">}</div></div><div class=""><br class=""></div><div class="">// it is very hard to disambiguate between pattern and return value even though for the compiler it could be doable</div><div class=""><div class="">match(1) { cases</div><div class="">&nbsp; &nbsp; 1, 3: 10, 2, 4: 20, default: 30</div><div class="">}</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">There should be a more visible distinction between two "<span style="color: rgb(51, 51, 51); background-color: rgb(255, 255, 255);" class="">case-item-map" <b class=""><u class="">like</u></b> "|". But we have to consider "expression-patterns" where operators (like "|") are ambiguous.</span></div><div class=""><span style="color: rgb(51, 51, 51); background-color: rgb(255, 255, 255);" class=""><br class=""></span></div><div class=""><span style="background-color: rgb(255, 255, 255);" class=""><font color="#333333" class="">-&nbsp;Maximilian</font></span></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">Am 04.02.2016 um 18:48 schrieb Paul Ossenbruggen &lt;<a href="mailto:possen@gmail.com" class="">possen@gmail.com</a>&gt;:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">That is a good point and I forgot about that. There are frequent cases where what I am dealing with is not hashable and it is generally a lot of work to make it hashable, including adding a heading function which if done wrong, can lead to errors. &nbsp;<br class=""><br class="">Sent from my iPhone</div><div class=""><br class="">On Feb 4, 2016, at 8:38 AM, Charles Constant via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">I still vote for keeping "cases"</div><br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I see it as a replacement for dictionary literal "pattern matching":<br class=""></div><div class=""><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(209,47,27)" class=""><span style="" class="">[</span><span style="color:rgb(39,42,216)" class="">1</span><span style="" class=""> : </span>"one"<span style="" class="">, </span><span style="color:rgb(39,42,216)" class="">2</span><span style="" class=""> : </span>"two"<span style="" class="">, </span><span style="color:rgb(39,42,216)" class="">3</span><span style="" class=""> : </span>"three"<span style="" class="">][</span><span style="color:rgb(39,42,216)" class="">1</span><span style="" class="">] ?? </span>"undefined"</div></div><div class=""></div></div></blockquote><div class=""><br class=""></div><div class="">A dictionary needs keys that are Hashable. A dictionary produces an optional. We've discussed this, and more, earlier in the thread.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">Even though it would be nice to have but I don’t think that I would use it frequently.</div></div></blockquote><div class=""><br class=""></div><div class="">Granted, it's a bit ugly, but given the choice, I would pick "cases" over "case case case case ..." every time.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">In addition, to be more consistent with "case", "cases" would introduce pattern matching which doesn’t seem right with this concise syntax.</div></div></blockquote><div class=""><br class=""></div><div class="">I haven't thought this through. It just bums me out a little to replace the switch with something that still has imho unnecessary verbosity.</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>