<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div>Am 16.02.2016 um 06:56 schrieb Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><div><span></span></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div></div><div>+1</div><div><br></div><div>I still don't understand what's the problem with</div><div><br></div><div>// mutating: verbs</div><div>func merge(set: Set) // or unite(with set: Set)</div><div>func intersect(with set: Set) // added label "with" to make semantics clear</div><div>func remove(set: Set) // or subtract</div><div>func removeIntersectionWith(set: Set) // or something else</div></div></blockquote><div><br></div>Oops, the last one is obviously named wrongly.<div>We might use one of Ricardo's suggestions instead.</div><div><br></div><div>-Thorsten </div><div><br><blockquote type="cite"><div><div><br></div><div>// non-mutating: nouns</div><div>func union(set: Set) -> Set</div><div><div><span style="background-color: rgba(255, 255, 255, 0);">func intersection(set: Set) -> Set // maybe use label "with" here, too, for symmetry</span></div></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">func difference(set: Set) -> Set</span></div></div><div>func symmetricDifference(set: Set) -> Set</div><div><br></div><div>Much better than </div><div>-Thorsten </div><div><br></div><div><br>Am 15.02.2016 um 21:17 schrieb Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><div dir="ltr">+1. Would rather see us retain the (IMHO) correct math-based nomenclature, and come up with rules for handling cases where there are 'terms of art' that don't fit neatly into the standard ruleset.<div><br></div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 11:46 AM, Xiaodi Wu via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap">It pains me that well-known math terms and even whole protocols get lopped off because of vagaries of the English language. New thought prompted by some of these suggestions:<br><br>There's a fairly circumscribed number of commonly used mathematical terms of art. These describe for the most part functions for which there are no noun/verb pairs. Suppose then, we have a rule:<br><br>Define these mathematical functions only outside types, as though they were operators. If (as it seems), operators are an acceptable option for Set but for the nomenclature, surely these functions can be acceptable as well. Then you would have:<br>union(a, b) // non-mutating<br>union(&a, b) // mutating<br><br>This is unambiguous, terse, conformant to expectations arising from familiarity with math, and recognizably English, and you can still have a SetAlgebra protocol if it can ensure these functions exist for conforming types as Equatable ensures ==. "Pollution" of the global scope would be limited to commonly used math terms, which should not be coopted for another purpose in any case.</div><div class="HOEnZb"><div class="h5"><br><br><br><br><br><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 15, 2016 at 1:17 PM Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
on Mon Feb 15 2016, Xiaodi Wu <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
> Agreed that "union" creates an expectation that it's non-mutating.<br>
><br>
> There's no real point in pushing back on whether UIs are more or less<br>
> important for Swift than math.<br>
><br>
> Problem is, the moment you name something SetAlgebra, you've set user<br>
> expectations that it's a 'math API'. Those ain't UI terms.<br>
<br>
Yep. As I mentioned in<br>
<<a href="http://news.gmane.org/find-root.php?message_id=m2pow033r1.fsf%40eno.apple.com" rel="noreferrer" target="_blank">http://news.gmane.org/find-root.php?message_id=m2pow033r1.fsf%40eno.apple.com</a>>,<br>
we have a semantic muddle here. Given where this is all headed, I am<br>
somewhat inclined to retire the SetAlgebra protocol (it only seems to<br>
have 3-4 uses on github), but renaming it could be another viable<br>
option.<br>
<br>
> On Mon, Feb 15, 2016 at 11:25 AM Dave Abrahams via swift-evolution <<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
>><br>
>> on Mon Feb 15 2016, Maximilian Hünenberger <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>><br>
>> wrote:<br>
>><br>
>> > I also prefer (2). Isn't "union", "intersection", ... a "Term of Art"?<br>
>> > See the guidelines under "Stick to the established meaning".<br>
>> ><br>
>> > So we should stick to the mathematical naming.<br>
>><br>
>> My understanding of the rationale for the current direction is that the<br>
>> domain of building GUI apps is more important than that of math, so the<br>
>> look and feel of sets should match those of most other (non-math) APIs.<br>
>><br>
>> > Since these terms almost always return a new instance we should have<br>
>> > an obvious mutating version with an "inPlace" suffix.<br>
>> ><br>
>> > - Maximilian<br>
>> ><br>
>> >> Am 14.02.2016 um 22:37 schrieb Xiaodi Wu via swift-evolution<br>
>> >> <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br>
>> >><br>
>> >> From a 10,000-ft view, I'd suggest that the noun/verb rule<br>
>> >> consistently runs into a problem with mathematical terms.<br>
>> >><br>
>> >> In general, mathematical functions don't have verb forms. You<br>
>> >> 'compute' the reciprocal, or 'find' the reciprocal, or 'take' the<br>
>> >> reciprocal, you don't 'reciprocate' or 'reciprocalize'. Likewise for<br>
>> >> trigonometric functions, etc. Nor can you really 'cross produce'...<br>
>> >><br>
>> >> So consistent is this trend that where two words might be noun/verb<br>
>> >> counterparts, like intersect/intersection and<br>
>> >> transform/transformation, common math usage treats both as<br>
>> >> acceptable nouns.<br>
>> >><br>
>> >> In colloquial usage, you might verb the noun, but then by definition<br>
>> >> the verb and noun become the same. Then, to generate a noun<br>
>> >> phrase/participle/etc. that looks different from the verb, you have<br>
>> >> to noun-ify the verbed noun.<br>
>> >><br>
>> >> Without an exception for mathematical function names, the only<br>
>> >> solution to fulfill these new Swift rules are clobbering the<br>
>> >> well-known math name or not using the math name at all. Indeed all<br>
>> >> proposed solutions so far come down to one of four options, either<br>
>> >> applied globally or only to sets for now, punting the rest down the<br>
>> >> road:<br>
>> >><br>
>> >> (1) Abandon the rule, making a new one (e.g.: .=)<br>
>> >> (2) Make an exception to the rule for math function names<br>
>> >> (3) Generate the least offensive noun-ified verbed nouns based on math<br>
>> function names<br>
>> >> (4) Don't use math function names<br>
>> >><br>
>> >> (1) is off the table, according to the core team. My vote at this<br>
>> >> point is for (2), and I see that a few others have voiced that<br>
>> >> opinion. It'd be nice to get a sense from the core team if that is<br>
>> >> even a possibility. (3) has elicited a lot of discussion and<br>
>> >> visceral reactions. (4) might be workable for sets alone but surely<br>
>> >> can't be a generalized solution for all mathematical concepts to be<br>
>> >> encountered in Swift.<br>
>> >> On Sun, Feb 14, 2016 at 3:14 PM Tyler Fleming Cloutier via<br>
>> >> swift-evolution<br>
>> >> <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>> >>>> On Feb 14, 2016, at 12:48 PM, Dave Abrahams<br>
>> >>>> <<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>> wrote:<br>
>> >>>><br>
>> >>>><br>
>> >>>> on Sun Feb 14 2016, Tyler Fleming Cloutier <<a href="http://cloutiertyler-at-aol.com">cloutiertyler-AT-aol.com</a>><br>
>> wrote:<br>
>> >>>><br>
>> >>>>>> On Feb 14, 2016, at 8:27 AM, Dave Abrahams<br>
>> >>>>>> <<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>> wrote:<br>
>> >>>>>><br>
>> >>>>>><br>
>> >>>>>> on Sat Feb 13 2016, Tyler Fleming Cloutier<br>
>> <<a href="http://cloutiertyler-at-aol.com">cloutiertyler-AT-aol.com</a>> wrote:<br>
>> >>>>>><br>
>> >>>>>>> I would, personally, be very careful about discarding the<br>
>> mathematical<br>
>> >>>>>>> terms since they are so widely used and understood.<br>
>> >>>>>><br>
>> >>>>>> IMO it's better to leave them aside than to use them in “creative”<br>
>> ways<br>
>> >>>>>> that might be misleading.<br>
>> >>>>><br>
>> >>>>> Agreed. I’m all for that.<br>
>> >>>>><br>
>> >>>>>>> One issue is that it’s going to be hard to search for the<br>
>> operation I<br>
>> >>>>>>> want considering I won’t be looking for "func<br>
>> >>>>>>> invertingMembershipOfContentsOf(other: Self) -> Self”. I’m<br>
>> concerned<br>
>> >>>>>>> people are going to have to do mental gymnastics to build the map<br>
>> from<br>
>> >>>>>>> math term to Swift function every time they want to look for a set<br>
>> >>>>>>> operation method. “func invertingMembershipOfContentsOf(other:<br>
>> Self)<br>
>> >>>>>>> -> Self” doesn’t exactly seem to fit in the commonly held Venn<br>
>> diagram<br>
>> >>>>>>> mental model of set operations. You could always have a<br>
>> documentation<br>
>> >>>>>>> comment that specifies the mathematical term so that people didn’t<br>
>> >>>>>>> have to double check themselves every time.<br>
>> >>>>>>><br>
>> >>>>>>> That being said, if the autocomplete issue is not a concern, I’m of<br>
>> >>>>>>> the opinion that the names Ricardo proposed are short, clear, and<br>
>> are<br>
>> >>>>>>> not so hard to fit to my Venn diagram mental model.<br>
>> >>>>>><br>
>> >>>>>> +1<br>
>> >>>>>><br>
>> >>>>>>> However, I tend to think that if there has to be this much dancing<br>
>> to<br>
>> >>>>>>> name a set of fundamental operations, the guidelines aren’t<br>
>> >>>>>>> accomplishing their goal.<br>
>> >>>>>><br>
>> >>>>>> I can't disagree.<br>
>> >>>>>><br>
>> >>>>>>> It’s going to make it that much harder for people do design their<br>
>> own<br>
>> >>>>>>> APIs. I'm having quite a time trying to conform Mattt’s Surge API<br>
>> to<br>
>> >>>>>>> the guidelines.<br>
>> >>>>>><br>
>> >>>>>> Please explain in detail. Without details we don't know what's<br>
>> wrong<br>
>> >>>>>> with the guidelines.<br>
>> >>>>><br>
>> >>>>> Ah, I apologize. I’ve gone into detail about this API on the list<br>
>> >>>>> before, but I should have included the details here.<br>
>> >>>>><br>
>> >>>>> Here are my previous posts:<br>
>> >>>>><br>
>> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007560.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007560.html</a><br>
>> >>>>> <<br>
>> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007560.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007560.html</a><br>
>> ><br>
>> >>>>><br>
>> >>>>> Basically the issues come down to the following. The Accelerate<br>
>> >>>>> framework typical operates in a non-mutating way. This means that my<br>
>> >>>>> API only has non mutating member functions and I should use the<br>
>> ed/ing<br>
>> >>>>> rule according to the guidelines to name my methods.<br>
>> >>>>><br>
>> >>>>> This is very difficult for some methods. I’m able to frequently get<br>
>> >>>>> around the problem for things like “sin” or “arctan” by keeping them<br>
>> >>>>> as global functions, but I can’t do that for a number of<br>
>> >>>>> methods. Consider:<br>
>> >>>>><br>
>> >>>>> remainder<br>
>> >>>>> dot (returns a scalar, thus there can’t be a mutating version, so<br>
>> >>>>> should I just call it dot? Guidelines don’t really comment on this)<br>
>> >>>>> mean (same as above)<br>
>> >>>>> cross<br>
>> >>>>> reciprocal<br>
>> >>>>> threshold<br>
>> >>>>> copysign<br>
>> >>>>> fastFourierTransform<br>
>> >>>>> pow (arguably the method version should be called raisedTo)<br>
>> >>>>><br>
>> >>>>> I could force all these to be global functions only, but these are<br>
>> not<br>
>> >>>>> as cut and dry as “sin” or “arctan”. I feel like I’d be splitting my<br>
>> >>>>> API up into two parts just based on the fact that it’s difficult to<br>
>> >>>>> use the ed/i</blockquote></div></div></div></blockquote></div></div></div></blockquote></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></div></body></html>