+1 for consistency. —A
> On Jun 17, 2016, at 12:04 PM, Patrick Pijnappel via swift-evolution > <[email protected]> wrote: > > You could make the exact same arguments about `sin`. > > – What sin(x) should do is unambiguous, unlike array.filter { ... }. > – There's very significant brevity issues here, e.g. hyperbolicArcTangent() > vs atanh(). > – The relevant metric of the strength of a term of art would be for how many > users it already is a very much ingrained term (i.e. not how long it has been > around). For sin() this is the case for pretty much anyone who has done > high-school math. Conversely, map/filter/reduce will only be significantly > ingrained for experienced users of languages that are functionally-centered > enough to regularly use these, which is a much smaller percentage (though not > insignificant). > > Let me turn your question around: What concrete benefits do we gain from > modifying terms which are extremely widely recognized? It is not consistent, > but is there any reason to believe that causes actual confusion? If not, then > why fix what isn't broken? > > The benefits of renaming: > – It makes learning easier as it establishes a consistent way to read Swift > methods right from the start. > – It would help users in intuitively learning consistent naming for their own > methods, even if they haven't read the API guidelines. > – It allows defining e.g. an in-place filter variant. > > I agree with your points on the problems with dropFirst/dropLast btw. > > On Fri, Jun 17, 2016 at 4:05 PM, Vladimir.S <[email protected] > <mailto:[email protected]>> wrote: > On 17.06.2016 15:58, Patrick Pijnappel wrote: > I suggest to leave map+flatMap+reduce as-is as true terms-of-art > > > Question still stands, what benefits do we gain from using the /exact/ > terms that are not present in the slightly modified ones? > > I don't know :-) I just see that many against renaming of > map/filter/reduce/etc and suggest a compromise : we leave map/reduce as-is, > but nothing else should be an exception to the naming rules. > > > On Fri, Jun 17, 2016 at 2:26 PM, Patrick Pijnappel > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > wrote: > > `map`, `filter`, and `reduce` are *the* higher-order functions. > Almost anything with any kind of block/lambda/closure feature > supports them (I'm giving the side-eye to Foundation here), and all > three names are backed by *very* strong conventions > > > > If `map`, `filter`, and `reduce` are not covered by the term-of-art > rule, we might as well rename it to the sin()-and-Int rule, because > I don't know what else it would cover. There is remarkable > consistency in the naming of these operations across dozens of > languages. > > > The point the proposal raises is that the modified versions preserve > the the terms of art in all the senses that matter (i.e. all the > benefits like recognition etc. still apply). > > On Fri, Jun 17, 2016 at 2:12 PM, Vladimir.S <[email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > On 17.06.2016 8:02, Patrick Pijnappel via swift-evolution wrote: > > -1, for the same reasons stated on the thread. These are > neither > guaranteed to be mutating or non-mutating until you get to > Collection. > Changing map() to mapped() would be lying to the developer > some of the > time about the mutability of the interface. > -DW > > > Actually the -ed/-ing suffix is *not *intended to guarantee > non-mutatability. It merely communicates whether it is a > "return-a-transformed-version-of-the-instance"-type method as > opposed to an > in-place mutation. Clearly these are not in-place forms. Note > that this is > my interpretation of the intent of the guidelines (or what > should be the > intent) – if the core team agrees perhaps this deserves > clarification in > the document. > > > Totally agree with you. I also understand this rule as separation > of "in-place"/"returns transformed version". I.e. the suffix should > say just "result of this operation will be returned and should be > assigned to other instance variable". Otherwise, as I understand, > ANY method that will touch or iterate the Sequence *could* mutate > it and so potentially we should have no -ing/-ed methods for > Sequence - no? > > > These functions are different than for example `sort` > because there > can’t be a general mutating method of `map`. A variable of > type `[A]` > can’t be mutated to hold a `[B]` which would be the result > of a map > from `A -> B`. > > > There could definitely be an in-place variant of filter. While > a /fully/ > general method would not be possible for the others, an user might > reasonable expect in-place variants of map/flatMap if T == U as > with e.g. { > $0 * 2 } or Optionals, and of dropFirst/dropLast if SubSequence > == Sequence > as with e.g. String. > > Also note that the -ed/-ing rule should not be merely for > ambiguous cases, > it should tell the user that the main use of the method is > returning a > transformed version of the instance. Having this be a rule you > can depend > on is important. > > > +1 > > > -1 The Term of Art argument is very strong with these > functions. I > prefer them as-is. > > > What specific benefits do we obtain from using the /exact > /terms of art vs. > the very slightly modified versions proposed? > > > Although I believe we can leave map&reduce as-is, I can understand > if we'll change them to mapped/reduced and will have consistent > naming everywhere, don't think this will cause any confusion for > one who will start to use them. In any case, we can add a hint in > compiler like "did you mean 'mapped'?". > > > > On Fri, Jun 17, 2016 at 3:24 AM, Brent Royal-Gordon via > swift-evolution > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>>> wrote: > > > The 'reduce()' at its core take an array of element and > reduce it to single element (could be of a different type) as > such it cannot ever be mutating (if one really want it, one > could reduce an array to the same array but it is not the goal > of the function). For this one it sound to me nearly like > asking to rename 'max()' to 'maxed()', 'count' to 'counted' or > implement a 'summed()' instead of a 'sum()' for [Int]. > > `max`, `count`, and `sum` are all nouns—at least in the > senses they are > meant in those calls—so they do not take the -ed/-ing > suffixes to form > immutable variants. Instead, they would take the `form` > prefix to form > mutable variants, if they had them. > > `map`, `filter`, and `reduce`—at least in the senses they > must be > interpreted in for the names of those calls to make > sense—are verbs, > and so they *would* normally take -ed/-ing suffixes. > However, as > broadly-accepted terms of art, we have left them alone > until now. > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > <mailto:[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
