On Sat, Jun 11, 2016 at 2:53 PM, Thorsten Seitz <[email protected]> wrote:
> > > Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution < > [email protected]>: > > On Fri, Jun 10, 2016 at 6:10 AM, Karl <[email protected]> wrote: > >> -1 >> >> * Swift is explicitly a C-family language. In most or all other C-family >> languages, for loop statements allow specification of conditions for >> exiting the loop but not for filtering. Therefore, Swift's use of `where` >> is unprecedented and needs to be learned anew by every user of Swift. >> >> >> When was this decided? I distinctly remember some bloke under Craig >> Federighi’s hair saying that it was time to “move beyond” C and essentially >> ditch legacy conventions which no longer make sense. >> > > I think you misunderstood my argument here. I don't mean that we should > yoke ourselves to C conventions, and we should absolutely ditch C > convention when it doesn't make sense. The big-picture argument here is > that `where` doesn't pass the bar of correcting a C convention that no > longer makes sense. > > FWIW, on the topic of syntax choices, here is what Chris Lattner had to > say on this list: > > Kevin got it exa*c*tly right, but I’d expand that last bit a bit to: >> “… pi*c*king the one that is most familiar to programmers in the >> extended *C* *family* is a good idea.["] >> The extended *C* *family* of language (whi*c*h in*c*ludes *C*, *C*++, Obj >> *C*, but also *C*#, Java, Javas*c*ript, and more) is >> an extremely popular and widely used set of languages that have a lot of >> surfa*c*e-level similarity. I >> don’t *c*laim to know the design rationale of all of these languages, >> but I surmise that this is not an >> a*c**c*ident: programmers move around and work in different languages, >> and this allows a non-expert in the >> language to understand what is going on. While there are things about *C* >> that are really unfortunate IMO >> (e.g. the de*c*larator/de*c*laration spe*c*ifier part of the grammar) >> there is a lot of goodness in the basi >> *c*operator set, fo*c*us on dot syntax, and more. >> I do agree that there are some benefits to dit*c*hing bra*c*es and >> relying on indentation instead, but there are >> also downsides. Deviating from the *C* *family* in this respe*c*t would >> have to provide **overwhelmingly** large >> advantages for us to take su*c*h a plunge, and they simply don’t exist. > > > >> As I understand it, Swift is a new language with new conventions. It is >> desirable to align as many of those as possible with existing conventions >> so as to be easily learned, but if you limit Swift to other languages >> conventions you deny it any identity. Did Python ask anybody’s opinion >> before dropping curly-braces? Did people learn whatever Perl is supposed to >> be? Look at C’s hieroglyphic for loops! >> > > I don't think we disagree here. > > >> >> Realistically, “for … in … while” is not going to cause incredible >> confusion. Removing it would cause a lot of frustration. You can’t on the >> one hand say our users are comfortable with the axioms of C’s hieroglyphic >> loops, and on the other hand say “for x in y while" is confusing. >> >> Again, as I said, once you've mastered something, by definition you find >> it not confusing. Why should we doom x% of new users to writing a loop >> incorrectly at least once when we don't have to? >> >> >> Ah, but if you’re not “doomed” to failing once, how will you ever master >> anything? Nobody knew how to write a C for-loop until someone showed them >> (and even then…). Nobody is going to just open a REPL and start writing >> code, with zero prior understanding of what Swift syntax looks like. >> > > The thought here is along the lines of what Chris said, quoted above, and > repeated here: "The extended C family of language [...] is an extremely > popular and widely used set[;] programmers move around and work in > different languages, and [aligning to expectations arising from other C > family languages] allows a non-expert in the language to understand what is > going on." By contrast, the `where` clause violates that expectation and I > do not see "overwhelmingly large advantages" for doing so. > > > What about C#'s `where` then? As C# is a member of the C family languages > `where` is not violating expectations! > C# does not have a where keyword for its foreach loop, afaik. > > -Thorsten > > > > >> >> * The word "where" does not consistently imply `break` or `continue`. In >> current Swift, `where` implies `break` in the context of a `while` loop and >> `continue` in the context of a `for` loop. Some users intuitively guess the >> correct meaning in each context, while others guess the wrong meaning. >> Therefore, the only way to learn for sure what `where` means in any context >> is to read the rulebook. That, by definition, means that this is >> unintuitive. >> >> >> I didn’t even know while loops supported “where”. I can’t even imagine >> what that would look like, or how I would reason about one if I saw one. I >> Googled around a little bit and couldn’t find any examples. If they exist, >> sure, go ahead, get rid of them. Nobody will miss them. >> > > Actually, we had a *huge* chain where there were definitely people who > said they would miss them, even though as you said it appears scarcely used > and not very well known. The pernicious problem with it was that it forced > even unrelated boolean assertions to be chained with `where`, as in: > > ``` > while let x = iterator.next() where y < z { ... } > ``` > > >> It definitely makes sense on ‘for’, though. Lots and lots of people will >> miss that; it’s a pretty well-known feature. >> > > (See Erica's statistics below.) > > Also, after everything you said, it’s still not unintuitive. That is not >> how languages work at all. Languages spoken by human beings are always >> ambiguous to some extent, and we use context to determine which meaning is >> correct: >> >> (Quote from >> https://research.googleblog.com/2016/05/announcing-syntaxnet-worlds-most.html >> ) >> >> One of the main problems that makes parsing so challenging is that human >> languages show remarkable levels of ambiguity. It is not uncommon for >> moderate length sentences - say 20 or 30 words in length - to have >> hundreds, thousands, or even tens of thousands of possible >> syntactic structures. A natural language parser must somehow search through >> all of these alternatives, and find the most plausible structure given >> the context. As a very simple example, the sentence "Alice drove down the >> street in her car" has at least two possible dependency parses: >> >> The first corresponds to the (correct) interpretation where Alice is >> driving in her car; the second corresponds to the (absurd, but >> possible) interpretation where the street is located in her car. The >> ambiguity arises because the preposition “in" can either >> modify drove or street; this example is an instance of what is >> called prepositional phrase attachment ambiguity. >> >> >> Even algebra is not completely unambiguous - you need to use BODMAS rules >> to disambiguate potential meanings. >> It’s this context which I think you’re missing when zooming in at the >> word “where”: >> >> - The context that this is a variation of a ‘for x in y’ loop. We know >> that it loops through every item in ‘y' and assigns it ‘x’. It is literally >> Section 2 of the 'Swift Tour' - you learn how to assign a variable, and >> then you learn about the “for x in y” loop. Everybody should recognise it. >> - The context that ‘x’ is the subject, so ‘where’ is clearly a condition >> for x to fulfill >> - The context that ‘where’ occurs after ‘in’, so it follows the order in >> which its written: ‘for every x in y, where such-and-such is true, do …” >> - The “for x in y” loop is a data-driven loop. It doesn’t even have a >> loop index. It is not like a C for loop and you shouldn’t expect to reason >> about it that way. >> >> * There are other ways to break from a loop or continue to the next >> iteration without performance penalty. Nearly all of these serve more >> general purposes than a `where` clause. Some of these (such as `if` or >> `guard`) would already be familiar to a new user before they encounter >> loops, assuming a typical order for learning a programming language. Many >> of these (such as filtering methods on collections, or simply `if`) would >> be familiar to a user of another C-family language. Therefore, the `where` >> clause provides no independent utility, is not more discoverable than its >> alternatives, and is not required for progressive disclosure of an >> important facility to a learner (i.e. a simplified syntax for those who may >> not be ready for the advanced concepts needed to use a more fully-featured >> alternative). >> >> >> You say the points in favour of removal are not handwavey, but I’m still >> not convinced. “There are other ways to go to where this shortcut goes” is >> not reasoning. And I’d definitely argue that it is more discoverable than >> the ‘guard’ statement. The guard statement is stone-dead last at the end of >> a massive “Control-Flow” page. I would guess that most first-time readers >> skip those topics for later. >> > > You cannot say the same about `if`. > > >> >> The point here is that this is not a slippery slope. If `where` offered >> independent utility, then some confusion alone probably wouldn't be enough >> to justify removal, though it may justify some consideration for change. >> However, as the extensive discussion has shown, there is nothing `where` >> can do that something else can't do better. I know you like it for style, >> but that's not sufficient grounds for keeping something confusing, IMO. >> >> >> It’s more readable. It does that better. >> > > Earlier in this thread and others, I gave my reasoning where I disagree > with this assertion about being more readable. > > >> The tests also seem to show that (bizarrely) it’s also slightly faster >> than the alternatives. >> > > I don't believe there has been any demonstration that it's faster than > `guard` or `if`. I would be shocked if that were the case. > > >> >> Karl >> >> On 10 Jun 2016, at 08:25, Xiaodi Wu via swift-evolution < >> [email protected]> wrote: >> >> On Fri, Jun 10, 2016 at 12:48 AM, Brandon Knope <[email protected]> wrote: >> >>> >>> >>> On Jun 10, 2016, at 1:08 AM, Xiaodi Wu via swift-evolution < >>> [email protected]> wrote: >>> >>> On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <[email protected]> >>> wrote: >>> >>>> >>>> Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution < >>>> [email protected]> a écrit : >>>> >>>> There have been, in previous threads, several examples given where >>>> users of Swift have found the behavior of `where` to be misleading and >>>> confusing. >>>> >>>> >>>> Sorry Xiaodi, but beside you (on multiple instances), and recently >>>> Erica, I have do not recall hearing that many voices saying that 'where' is >>>> confusing. >>>> >>> >>> Shawn Erickson wrote this to the list just yesterday: >>> >>> "I support your position on the use of where and while/when being >>> confusing in the loop statement. I (and I know others) have for example >>> used where in a loop statement mistakenly thinking it would terminate the >>> loop early but of course learned that it basically filters what causes the >>> loop body to be executed. After the fact that made sense to me but it >>> didn't click at first." >>> >>> >>> Couldn't we find examples of anyone being confused at any syntax? >>> Especially with an unfamiliar construct in a new language. >>> >>> If people find the new proposed syntax confusing, do we pull that too? >>> At what point do we stop? >>> >> >> That is why I favored (1) removal of the confusing syntax altogether; and >> (2) this proposal, which involves aligning the confusing syntax with an >> existing syntax. In short, no new syntax to get confused about. >> >> Yes, there's was maybe even less voices stating that it is not confusing, >>>> but which group is more vocal? >>>> >>>> Maybe I have been recently corrupt by Solid SQL queries: >>>> select * from PEOPLE_TABLE where AGE_FIELD = 100 >>>> >>>> Or by my (likely) broken English: >>>> The places where I had the most fun >>>> >>>> But, to me, where can only suggest some filtering (thus tag to a for .. >>>> in .., continue if not matching). >>>> >>> >>> I'm glad that you find it very clear. I do as well. That does not mean >>> it is clear to everyone. >>> >>> >>> I still have yet to see widespread confusion of this. A few people >>> learning swift here or there, but once they learn the syntax...do they >>> still find it confusing? >>> >> >> >> I expect some concrete data on stuff like this...especially with proposed >>> syntax changes. >>> >>> Without concrete examples, what would stop one from coming in here and >>> waving their hands around to push *what they like* through? >>> >> >> Here's what's not handwavy: >> >> >> >> >> Conclusion: the `where` clause is unprecedented, unintuitive, provides no >> independent utility, is not more discoverable than alternatives, and is not >> required for pedagogical reasons; however, it has been used incorrectly by >> at least some users. Therefore, it is harmful and ought to be removed or >> reformed. >> >> I know there's a linguist on the list, maybe he could comment on whether >>>> or not using 'where' as a filter is proper or an abomination. >>>> >>>> I do not think that because something is confusing to some, or at >>>> first, that it warrant removal from the language. >>>> >>> >>> It is a very bad sign if something is confusing at first, especially to >>> a significant proportion of users. It's true by definition that once you >>> have mastered something you are no longer confused by it. >>> >>> >>> Again, where is this significant proportion of users? I don't mean to >>> hound you on this, but I am genuinely curious where this is all coming from. >>> >> >> We were talking about the hypothetical something here and what the bar >> should be for removal from the language. My response is that being >> confusing at first sight *is* a legitimate consideration for removal from >> the language. If something turns out to be a confusing way to describe a >> straightforward concept, then the more widespread the confusion, the more >> urgent its removal. >> >> >>> The burden of evidence is on the proposers of these ideas. >>> >>> As has been stated on this list, education is a valid and important >>> consideration for Swift. If something is confusing rather than difficult >>> (and the *concept* of filtering a list is not at all a difficult concept), >>> and if the same underlying concept can already be invoked in alternative >>> and equivalent ways that are not confusing, then it's a no-brainer that the >>> confusing thing is harmful to the language and should be removed on that >>> basis alone. >>> >>> >>> What is clear to one person may be confusing to another. There is no >>> perfect syntax that will not make it confusing for some users. >>> >>> ---- >>> >>> I really think it is important to come armed with more information with >>> these proposals. It's easy to say a significant proportion of people are >>> confused but it would make me much more comfortable to see this data to >>> back it up. >>> >>> What if we are spinning our wheels for no reason on a feature that >>> *most* don't find confusing? What if we make a bigger proportion of those >>> who did understand it more confused now? >>> >> >> >> >> >>> Brandon >>> >>> >>> By analogy, Chinese and Japanese share difficult writing systems. Yet >>> many people use those languages daily without difficulty. Does that mean >>> there's not a problem? Far from it: in fact, you'll find that many >>> intelligent people have devoted their life's work to mitigating the issue. >>> Both Chinese and Japanese underwent a round of simplification in the 20th >>> century. Think about it: real languages used for daily life by a >>> significant fraction of the world's population were revamped for the >>> purpose of increasing accessibility to new learners. >>> >>> The by-value/by-reference is well define, but can be confusing at first. >>>> Same goes for eager/lazy processing, or escaping vs non-escaping closure, >>>> or even the difference between closure and function. But no one suggest to >>>> remove them. >>>> >>> >>> Value types vs. reference types is a concept (and a moderately advanced >>> one), eager vs. lazy processing is a concept (and a moderately advanced >>> one), and closures are a concept (and definitely an advanced one). >>> >>> Filtering a collection is a concept as well, and no one is suggesting >>> its removal. We are proposing to simplify and rationalize the syntax by >>> which filtering is invoked. If there were a way to dramatically simplify >>> the syntax surrounding value types and reference types so as to diminish >>> confusion, you can absolutely guarantee that there would be proposals to >>> change the syntax. If I could think of one tomorrow, you'd see a thread >>> tomorrow about it. I don't think I'm that smart though. >>> >>> >>>> Dany >>>> >>>> In fact, the first of these proposals began with a question: how does >>>> one write arbitrary Boolean assertions after a let binding? The answer (use >>>> `where`) was found to be misleading and confusing. >>>> >>>> I think you're being unfair to say that these proposals have no purpose >>>> other than an academic consistency. >>>> On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution < >>>> [email protected]> wrote: >>>> >>>>> As time goes on, I’m feeling more and more that these >>>>> consistency proposals are sorely misguided. Frankly, unless the syntax is >>>>> confusing or misleading, even once the developer has learned the guiding >>>>> principles of Swift, consistency is not a good argument for change. This >>>>> proposal is the perfect example of this. No one will find the use of >>>>> “where” in loops confusing, aside from those who will wonder why it was >>>>> removed from if statements. There is no misleading behavior or confusing >>>>> syntax here. This is just consistency for consistency’s sake. Once this >>>>> proposal is done, then another will be made to remove “where” from another >>>>> place in the language. Then another and another until it’s gone completely >>>>> and a very useful part of the language is removed in the name of >>>>> consistency. Which really just comes down to “where” isn’t used here, so >>>>> it >>>>> can’t be used there anymore. It’s death by a thousand cuts. >>>>> >>>>> >>>>> >>>>> Jon Shier >>>>> >>>>> >>>>> > On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution < >>>>> [email protected]> wrote: >>>>> > >>>>> > >>>>> >> On Jun 9, 2016, at 11:11 AM, Charlie Monroe < >>>>> [email protected]> wrote: >>>>> >> See my latest post - included results with -Ofast. But still, using >>>>> filter and lazy.filter is 10+% slower, which were the suggested >>>>> alternatives to `where`. >>>>> >> >>>>> >> >>>>> > >>>>> > I need to correct this misapprehension. >>>>> > My suggested alternative to where was and remains `guard`. >>>>> > >>>>> > -- E >>>>> > >>>>> > _______________________________________________ >>>>> > 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 >>>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> _______________________________________________ >> 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
