<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">At a theoretical level — if you add ‘if/where’ conditions to either acc or x then the function being performed can no longer be guaranteed to be commutative (especially if the ‘if’ uses ‘acc’ in it).<div class=""><br class=""></div><div class="">If the function is not commutative, then the reduce cannot be broken down and processed in parallel. </div><div class=""><br class=""></div><div class="">‘map’ (single values) don’t have this issue since it is a single value independent of all other values (so it can be processed in parallel - no problem).</div><div class=""><br class=""></div><div class="">‘fold’ by it’s definition either processes things synchronously left to right, or right to left — and not in parallel. </div><div class=""><br class=""></div><div class="">Swift reduce has a starting value and likely is just a fold, not a reduce (at least when it is compared to Scala; not sure about when it comes to big data).</div><div class=""><br class=""></div><div class="">Just a guess really though, at least it puts my mind to rest. </div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 2016-02-05, at 13:48:33, Thorsten Seitz <<a href="mailto:tseitz42@icloud.com" class="">tseitz42@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div class="">You are right, it seems that Scala is doing automatic unsplatting now. Why it doesn't work for reduce I can't say.<br class=""></div><div class=""><br data-mce-bogus="1" class=""></div><div class="">-Thorsten<br data-mce-bogus="1" class=""></div><div class=""><br data-mce-bogus="1" class=""></div><div class=""><br class="">Am 05. Februar 2016 um 07:01 schrieb Craig Cruden <<a href="mailto:ccruden@novafore.com" class="">ccruden@novafore.com</a>>:<br class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="msg-quote" style="word-wrap: break-word;" data-mce-style="word-wrap: break-word;">No, that cannot be the reason.<div class=""><br class=""></div><div class="">— this works</div><div class=""><div class="">val r2 = a.foldLeft(0) {</div><div class=""> case (acc, x) if x > 4 => println(x); acc + x</div><div class=""> case (acc, x) if x <= 4 => acc - x</div><div class="">}</div><div class=""><br class=""></div><div class="">— this does not.</div><div class="">val r3 = a.reduce {</div><div class=""> case (acc, x) if x > 4 => println(x); acc + x</div><div class=""> case (acc, x) if x <= 4 => acc - x</div><div class="">}</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On 2016-02-05, at 12:59:06, Thorsten Seitz <<a href="mailto:tseitz42@icloud.com" class="" data-mce-href="mailto:tseitz42@icloud.com">tseitz42@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">-Thorsten </div><div class=""><br class="">Am 04.02.2016 um 22:57 schrieb Craig Cruden via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">Off Topic a little.</div><div class=""><br class=""></div>I was playing around with the equivalent case - partial functions in Scala …. <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…. 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). </div><div class=""><br class=""></div><div class="">As far as I can tell, there is a little difference that prevents it. Swift reduce is probably the same as Scala’s foldLeft. 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. </div><div class=""><br class=""></div><div class="">Scala’s fold is either left to right, or right to left. `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. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On 2016-02-05, at 4:17:03, Paul Ossenbruggen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div 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. </div><div class=""><br class="">Thanks </div><div class="">- Paul </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 <<a href="mailto:m.huenenberger@me.com" class="" data-mce-href="mailto:m.huenenberger@me.com">m.huenenberger@me.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div 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=""> case 1, 3: 10</div><div class=""> case 2, 4: 20</div><div class=""> 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=""> 1, 3: 10,</div><div class=""> 2, 4: 20,</div><div class=""> 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=""> 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: #333333; background-color: #ffffff;" class="" data-mce-style="color: #333333; background-color: #ffffff;">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: #333333; background-color: #ffffff;" class="" data-mce-style="color: #333333; background-color: #ffffff;"><br class=""></span></div><div class=""><span style="background-color: #ffffff;" class="" data-mce-style="background-color: #ffffff;"><span style="color: #333333;" data-mce-style="color: #333333;" class="">- Maximilian</span></span></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">Am 04.02.2016 um 18:48 schrieb Paul Ossenbruggen <<a href="mailto:possen@gmail.com" class="" data-mce-href="mailto:possen@gmail.com">possen@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div 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. <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 <<a href="mailto:swift-evolution@swift.org" class="" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 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: #cccccc; border-left-style: solid; padding-left: 1ex;" data-mce-style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class="" data-mce-style="word-wrap: break-word;"><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: #d12f1b;" class="" data-mce-style="margin: 0px; font-size: 11px; line-height: normal; font-family: 'menlo'; color: #d12f1b;"><span class="">[</span><span style="color: #272ad8;" class="" data-mce-style="color: #272ad8;">1</span><span class=""> : </span>"one"<span class="">, </span><span style="color: #272ad8;" class="" data-mce-style="color: #272ad8;">2</span><span class=""> : </span>"two"<span class="">, </span><span style="color: #272ad8;" class="" data-mce-style="color: #272ad8;">3</span><span class=""> : </span>"three"<span class="">][</span><span style="color: #272ad8;" class="" data-mce-style="color: #272ad8;">1</span><span class="">] ?? </span>"undefined"</div></div><div class=""><br 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: #cccccc; border-left-style: solid; padding-left: 1ex;" data-mce-style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class="" data-mce-style="word-wrap: break-word;"><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: #cccccc; border-left-style: solid; padding-left: 1ex;" data-mce-style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class="" data-mce-style="word-wrap: break-word;"><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="" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution">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="" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="" data-mce-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" 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="" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></div></body></html>