Regards (From mobile)
> On Jun 11, 2016, at 9:59 PM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > > >> 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 exactly right, but I’d expand that last bit a bit to: >>>> “… picking the one that is most familiar to programmers in the extended C >>>> family is a good idea.["] >>>> The extended C family of language (which includes C, C++, ObjC, but also >>>> C#, Java, Javascript, and more) is >>>> an extremely popular and widely used set of languages that have a lot of >>>> surface-level similarity. I >>>> don’t claim to know the design rationale of all of these languages, but I >>>> surmise that this is not an >>>> accident: 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 declarator/declaration specifier part of the grammar) there is a >>>> lot of goodness in the basic >>>> operator set, focus on dot syntax, and more. >>>> I do agree that there are some benefits to ditching braces and relying on >>>> indentation instead, but there are >>>> also downsides. Deviating from the C family in this respect would have to >>>> provide *overwhelmingly* large >>>> advantages for us to take such 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. --> linq > >> >> -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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
