> On Mar 28, 2016, at 7:34 PM, Erica Sadun <er...@ericasadun.com> wrote:
>
>>
>> On Mar 28, 2016, at 6:19 PM, Dave via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>
>>> On Mar 25, 2016, at 4:45 PM, Dave Abrahams <dabrah...@apple.com
>>> <mailto:dabrah...@apple.com>> wrote:
>>>
>>> on Fri Mar 25 2016, davesweeris-AT-mac.com <http://davesweeris-at-mac.com/>
>>> wrote:
>>>
>>>> Can we rename `subtract` to `complement`, since that’s the correct
>>>> term? At least, I’m assuming that’s what `subtract` means… if not, I’m
>>>> confused.
>>>> https://en.wikipedia.org/wiki/Set_(mathematics)#Complements
>>>> <https://en.wikipedia.org/wiki/Set_(mathematics)#Complements>
>>>
>>> It's not just “complement,” because that means inverting set membership
>>> of everything in a finite domain. It would have to be “relative
>>> complement.” But “relative complement” lacks the directional
>>> implication that plagues terms like “difference,” but not “subtracting.”
>>
>> Fair points… I accidentally left off the argument label. May I amend my
>> suggestion to "rename `subtract(:)` to `complement(relativeTo:)`”? It just
>> seems to me that if we’re going to claim we’re implementing something, we
>> should adopt as much of its “standard" syntax and terminology as possible.
>> It makes Swift easier to use for those coming from other disciplines, IMHO.
>
> If you took 100 random developers off the street, and showed them code that
> said:
>
> set1.formRelativeComplement(set2)
>
> and
>
> set1.subtracting(set2)
>
> About 99.5% of them would understand the second better than the first on
> first read.
> The other 0.5 of a developer would be living somewhere near Boulder and
> growing
> his own hemi-pharmaceuticals.
With my amended suggestion, that would read "set1.formComplement(relativeTo:
set2)”. Either way, though, if you’re claiming that “complement(relativeTo:)”
or “complementRelativeTo(:)” shouldn’t be used because it’s too unrecognizable
compared to the roughly-analogous term “subtract", then surely “union”,
intersection”, and especially “symmetricDifference” all fail that test as well
when compared to some very well-known terms:
set1.or(set2) //union
set1.and(set2) //intersection
set1.xor(set2) //symmetric difference
(Plus, they work & play well with non-unicode operators.)
My issue isn’t so much that the proposal doesn’t implement the “correct”
mathematical notation, it’s that it uses a very formal-sounding name ("Set
Algebra”), and very nearly implements the basic operations of Set Theory (which
sounds very similar to “Set Algebra”), but then falls short by renaming just
one operation. Although, come to think of it, the proposal is missing
`cartesianProduct` as well… Oh well, at least it’s not in there under a
different name. :-)
> The problem with subtraction is that there isn't really a good noun/formNoun
> pair
> for it.
...
> In all my attempts at trying to brainstorm up a better word that would (1)
> retain
> the characteristics of mutating/non-mutating pairing while (2) being easy to
> read
> and understand, I could not come up with better than Dave A's
> subtract/subtracting.
> I may not like it aesthetically but when it comes to offering something
> better,
> I've got nothing.
I think these two statements have the same root cause: Pretty much everyone has
heard of subtraction, but the closest most people come to formally thinking
about sets is trying to decide who to pick for their fantasy football team. The
concept of operating on sets simply isn’t widespread enough for english to have
a colloquial word which conveys the required meaning. “Subtract” does come
close, but the AFAIK two concepts are only analogous in that subtraction is
often first taught from the POV of “imagine a set of x elements, take away y of
them, and count how many are left over” (see the first graphic in
https://en.wikipedia.org/wiki/Subtraction, if that doesn’t ring a bell). The
analogy doesn’t really work if your sets are, well, sets, as opposed to visual
representations of numbers. The only other “widely-recognized” term that I can
think of is “minus” (which I’d prefer over “subtract” because it seems less
precisely defined to me). Neither one is a noun, though, so they both break the
noun/formNoun pattern.
Speaking of nouns...
> That means either breaking the pair into two words that aren't well matched
> or using a noun that isn't that amazing, such as difference.
>
> set1.difference(set2)
> set1.formDifference(set2)
You can gain the requisite “directional implication” Dave Abrahams was talking
about by adding some labels:
set1.difference(from: set2)
set1.formDifference(from: set2)
> That said, I'd really like to see a Swift Doc markup that allows you to mark
> pairs of mutating/nonmutating functions, not from a compiler point of
> view but in doc markup.
>
> /// - nonmutatingVersion:
> /// - mutatingVersion:
>
> What group handles expansion of the markup keywords and how can I file a
> feature request asking for this to be added?
>
> Thanks,
>
> -- E
+1 :-)_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
