On Sat, Jun 11, 2016 at 5:03 PM, Thorsten Seitz <[email protected]> wrote:
> > > Am 11.06.2016 um 23:45 schrieb Xiaodi Wu <[email protected]>: > > > > On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz <[email protected]> > wrote: > >> >> >> Am 11.06.2016 um 22:29 schrieb L. Mihalkovic < >> [email protected]>: >> >> >> >> On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution < >> [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! >> >> >> Where is not exactly a part of c# it belongs to linq >> >> >> And that is not a part of C#?? >> > > SQL is a domain-specific language, and LINQ is an internal domain-specific > language with a language extension for C#. Neither is a general purpose > language. > > > I don't see how that is relevant especially given the prominence and reach > of SQL (which is turing complete, btw ;-) > It is relevant because the design of every language has to contend with trade-offs, and the trade-offs that make `where` a powerful and intuitive keyword in the context of a query language are different from the tradeoffs we must contend with in a general purpose language. HTML+CSS has also been proved Turing-complete; it is irrelevant to the question of whether the idioms of HTML+CSS are appropriate in a general purpose language. > Your example actually goes to one of Laurent's points. Should the Swift > core team or an enterprising community member propose a set of similarly > powerful tools, along with a set of language extensions that add syntactic > sugar for them, I (and I think Laurent, if I understand him correctly) > would absolutely be in favor of such an addition. But as it is, `where` is > an odd duckling. Just as you say, it looks like a component of a query > language, but it does no such thing. In a for loop, it does some filtering, > but until recently it functioned like a comma in `while` loops. Look at > those other keywords which make this sugar possible in C#: in your example, > `from` and `select`. We don't have any of that intrastructure in Swift. > > > We can simply extend the for-in-where loop for that like Scala does. No > need to add new syntax if an existing one can simply be generalized. > If you want to propose adopting Scala's `if`, you are free to start a discussion on that topic. Note how Scala also avoids use of the word `where`. > > -Thorsten > > > > >> The following is an example from MSDN with `where` clearly beaing a >> keyword: >> >> *var* numQuery = >> *from* num *in* numbers >> *where* (num % 2) == 0 >> *select* num; >> >> >> -Thorsten >> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
