Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Ted F.A. van Gaalen via swift-evolution]

Hi Taras

I’ve watched the WWDC15 video about Swift compiler optimization, read some more
in depth material about it. It is probably advanced in many aspects of 
optimization.
So, you might be correct to assume that the compiler can optimize
>  for(int i = x0; i In case I didn’t explain my reasoning clear enough, here is another attempt. 
> Swift already has a very powerful, compact tool that offers a strict superset 
> of the iteration semantics.
That is not (yet) the case, let alone a superset!

> I simply see no purpose into making the language more verbose and complicated 
> for no particular gain.

It doesn’t make the language more complicated, rather, the reverse is true.
If you want a less verbose language, learn APL, or J.
APL proves unintentionally the inverse relation between “verbose”and 
“complicated” :o) 

> What you do is argue for having two different syntactic styles for 
> accomplishing exactly the same thing,
> simply on the grounds of your personal dislike of one of them. 
It is not at all personal dislike, it is many years of die-hard experience 
with a multitude of programming languages and systems.
I don’t think in emotional terms about programming constructs but
solely about practical implications, usefulness, reliably and so on.

I assume this difference of opinion will remain...

 -
Coincidentally, today John Heerema, described here on swift-evolution 
exactly my point of view on these matters based on facts. 
read his text please. Thank you.
 -
I hope I am not too unfriendly here, Nothing personal. 
If I am in Zürich again it would be nice to discuss this with a beer. 
Although not so far from here, currently my finances prevent this.

Kind regards
Ted
www.ravelnotes.com

  == The problem is not what you add to a programming language
  == but what you remove!
  








> On 31.03.2016, at 14:59, Taras Zakharko  wrote:
> 
> 
>> On 31 Mar 2016, at 14:12, Ted F.A. van Gaalen  wrote:
>> 
>> Alas, I don’t understand you irritation, 
>> but it is your irritation, not mine.
> 
> Well, its quite simple: we are having a discussion here. You are claiming 
> that the collection-based iteration is inherently slower than a classical 
> numerical loop. This is incorrect. I have even sent around some C code that 
> uses different abstractions and shown that it compiles to the same machine 
> code. Yet you are consistently ignoring this. 
> 
>> Please note again, that “for ... in …”  always has 
>> some sort of collection type as its argument..
>> At run time, the content of a collection 
>> is in most cases unpredictable.
> 
> Again, incorrect. The simple collections that are relevant to this discussion 
> are based on trivial iterators that 

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Thorsten Seitz via swift-evolution]

Well said, Brent!

-Thorsten 

Am 23.03.2016 um 02:25 schrieb Brent Royal-Gordon via swift-evolution 
:

>> These may be compact, but some programmer may fell that they are not in 
>> control: do these "stdlib" seq(), c.filter() pre-calculate all the entries 
>> (wasting precious cpu cycle if one break out early)  or are each value 
>> dynamically created? Having an explicit legacy loop format gives a feel of 
>> control. So something like
>> 
>> for i from 2 to 1_000_000 by 1 where i % 2 != 0 while foundCount < 5 { 
>> print(i); foundCount +=1 }
>> 
>> sounds less magical and seems easier to predict than
>> 
>> for i in 2.stride(to:1_000_000, by:1).filter({ $0 % 2 != 0}).prefix(5) { 
>> print(i) }
>> 
>> and is still quite readable, even if it mixes for loop, while loop and even 
>> simple condition.
> 
> First of all, this example sucks. There are *many* ways to write it with 
> existing features which would be more understandable than the pile of random 
> code in your `for` loop. Here are a few:
> 
>for i in stride(from: 2, to: 1_000_000, by: 1) where i % 2 == 0 {
>print(i)
>foundCount += 1
>if foundCount >= 5 { break }
>}
> 
>for i in stride(from: 2, to: 1_000_000, by: 2) {
>print(i)
>foundCount += 1
>if foundCount >= 5 { break }
>}
> 
>for i in stride(from: 2, to: 1_000_000, by: 2).prefix(5) {
>print(i)
>}
> 
> I know you're trying to illustrate some features you'd like on the `for` 
> loop, but by choosing this example you're not realy challenging your proposal 
> enough for its disadvantages to be illustrated well. For instance, one thing 
> `stride` cannot currently do is apply a step that doesn't involve addition, 
> for instance by multiplying the number. But your `by` keyword suffers from 
> the same problem! To really add anything new, your proposal would have to be 
> vastly more complicated than what you describe here. It's not fair to say 
> "look how much simpler this is" while sweeping the actual complexity under 
> the rug.
> 
>> Sorry if the example is a bit dumb as is; but I was too lazy to provide some 
>> nice code instead of the simple print.
>> Can anyone tell if the filter.prefix above is lazy and that each number is 
>> create one by one?
>> The fact that using 1_000_000 above caused my playground to crash, seems to 
>> indicate that the list of number is pre-generated.
> 
> Yes, I can tell you without looking at anything that the second example is 
> greedy. `stride` acts lazy (it returns an instance which, when iterated over, 
> produces the values), but `filter` is greedy unless you explicitly use 
> `lazy`. If you don't know this, you can tell by looking at `filter`'s return 
> type, which is an Array.
> 
> Your "explicit" syntax, on the other hand, seems totally out of control. 
> Where do these features come from? What happens when you find something else 
> you want to do in a loop? Do you invent another keyword and give it a new 
> syntax? This *still* doesn't give you enough flexibility to express a `for` 
> loop which doubles the number; is that going to require a new keyword? How 
> many keywords is it going to take? Is anyone ever going to learn what all 
> these keywords mean? Are you going to have to re-read The Swift Programming 
> Language to decode every moderately complicated `for` loop?
> 
> (And how am I supposed to mentally parse your sea of undifferentiated 
> alphanumerics? Punctuation in a programming language helps you understand the 
> role of each part of it; your proposal's lack of punctuation makes it 
> difficult to read.)
> 
> The function/method-based approach requires a little more syntax and a little 
> more understanding of what's going on. But has huge advantages that I think 
> you're unfairly ignoring:
> 
> * It is simple. The `for` loop itself is quite uncomplicated. The only extra 
> features it has are the `case` clause, which can't be easily duplicated in 
> another way, and the `where` clause, which I've honestly never been totally 
> happy with.
> * It is reusable. Calls like `stride`, `filter` and `prefix` can be used even 
> outside a `for` loop.
> * It is extensible. If you need something new, you can add it, and it will be 
> just as accessible as anything the standard library's designers dreamed up.
> * It is documentable. By using functions and methods instead of keywords, 
> it's easier to look up what a particular feature does.
> * It is sustainable. If we have some kind of really specific looping 
> mechanism like you propose, every little feature we want will need a specific 
> design, evolution proposal, and implementation by the compiler team. That is 
> a completely unrealistic plan. Not even the C `for` loop took this 
> approach—it provided a *general* mechanism for plugging your own logic into a 
> loop.
> 
> Ultimately, piling on new keywords every time you think of a tiny variation 
> is simply bad language 

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Ted F.A. van Gaalen via swift-evolution]

Grüezi wohl Taras

you wrote:

> I find it quite irritating that you keep repeating these untrue facts. Again: 
> both for loops compile to exactly the same code. 


Alas, I don’t understand you irritation, 
but it is your irritation, not mine.

Please note again, that “for ... in …”  always has 
some sort of collection type as its argument..
At run time, the content of a collection 
is in most cases unpredictable.
Ergo: this implies that in these cases,
the compiler cannot optimize the collection 
part of the “for … in …” statement out of the way. 
In an attempt to overcome this restriction, 
it would need to analyze all entities that have 
influenced the content of the collection, 
which is virtually impossible.
 
I do not understand your aversion against 
the for loop I brought forward, as it does not 
conflict at all with the “for ... in …” construct 
and probably also does not stand in the way 
of possible future extensions that could be 
added to the "for in..” construct. 

E.g. For similar reasons one could be irritated by 
the brave attempts of some of us to supply 
most peculiar variants of “Strides", seemingly,
at least as seen from my limited perspective,
to compensate the loss of the classical for-loop’s
facilities...  
In spite of all this being very fascinating and 
creative, to me, this effort is comparable with
trying to climb the Eiffel tower, equipped
with boxing gloves and diving fins.
it could irritate me.. However it does not,
for the mere reason that I do not fully 
understand their motives and logical grounds...
Nevertheless, they might -or might not- 
have good reasons to do so, as we no 
doubt will find out sooner or later...
In any case, this does affect the collection-based
“for … in …” only, and has no impact on the 
“for v from v1 to v2 by vstep” 
that I am proposing. 



> Collection-based for loop can express exactly the same semantics, so why do 
> you need a new construct when you already have a perfectly good one to do the 
> job? 


For the simple reason that there are no collections involved: 
I have very clearly described and motivated it. 
Please read it again, thank you.

By the way, it is not a new construct as it has been
existing for decades.

I took the liberty to read about you on the internet. Interesting.

I’ve read that you have a degree in linguistics, 
which makes me assume that of all people, 
you’d understand that in most languages 
there are many different ways to express something,
and that the way to express or say something 
is mostly determined by contextual aspects... 
So in the light of this very specific knowledge
that you have, I fail to understand what your
objections are against the presence of 
two slightly different for-loop variants
that can co-exist easily and are effective,
each in its own different context?  

Last but not least, you might find this interesting:
(although I am almost sure you have read it before)

http://blog.oxforddictionaries.com/2014/09/george-orwell-newspeak/

and then most particularly in this text: 

“Newspeak goals and real-world ramifications”

I cannot completely clear myself from the association
of this with the removal of certain Swift language 
elements..


Met vriendelijke groeten.
TedvG


 

> On 31.03.2016, at 10:11, Taras Zakharko  wrote:
> 
> 
>> On 30 Mar 2016, at 22:05, Ted F.A. van Gaalen via swift-evolution 
>> > wrote:
>> 
>> Again I need to emphasize very strongly that this for-loop really 
>> has absolutely 
>>  nothing, nada, zilch, niente, nichts, niets, niks, rien, zero, nenio,
>> to do with the: 
>> 
>> for i in stride(…. 
>> 
>> or any other for in… variant working with collections.
> 
> Of course it does. Collection-based for loop can express exactly the same 
> semantics, so why do you need a new construct when you already have a 
> perfectly good one to do the job? 
> 

>> 
>> but, once again - 
>> provided you don’t want to do other operations
>> on the generated collection before iterating -  
>> a collection is used here totally unnecessary, 
>> which puts a burden on performance because the contents 
>> of a collection are unpredictable 
> 
> I find it quite irritating that you keep repeating these untrue facts. Again: 
> both for loops compile to exactly the same code. 
> 
>> It is also tedious to write and (as a matter of my personal taste) downright 
>> ugly.
> 
> Right, because 
> 
>  for d in stride(from:10, to: 5, by: 0-.1, tolerance: 0.01) 
> 
> is that much more tedious to write than what you propose
> 
> Best, 
> 
>  Taras
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Ted F.A. van Gaalen via swift-evolution]

I still would like to see this new for-loop statement be implemented in the 
next Swift version

 Examples:
 for v from 0.5 to 30.0 by 0.3// floating point types
 for v from 0 to 100 by 5   // Integer
 for v from 12.0 to -10.0 by -2  // Floating points backward 

the “by …” clause is optional for Ints only 


As previously written, a tolerance factor could also be implemented as optional,
allowing to “end on a humanly accepted boundary” so like in this example
the highest loop value would be 10.0 (+/- ca. 0.1) , not 9.9 :  
  
 for v from 0.0 to 10.0 by 0.1 tolerance 0.001 

// the “tolerance ..” clause is optional and allowed for floating point vars 
only


Again I need to emphasize very strongly that this for-loop really 
has absolutely 
 nothing, nada, zilch, niente, nichts, niets, niks, rien, zero, nenio,
to do with the: 

for i in stride(…. 

or any other for in… variant working with collections.

However inexplicably, in the previous discussions, a lot of people ***
tried desperately to replace this simple but precious gem, 
a miracle of astonishing beauty:   (sorry, got carried away a bit :o) 
  
for v from v1 to v2 by vstep 
 
with the collection based 

for in ….

The for in… is wonderful for collection based iterations, I use it 
all the time like
for thing in things // etc.



for d in 10.0.stride(to: 5.0, by: -0.1)
{
print(d)
}


but, once again - 
provided you don’t want to do other operations
on the generated collection before iterating -  
a collection is used here totally unnecessary, 
which puts a burden on performance because the contents 
of a collection are unpredictable 
It is also tedious to write and (as a matter of my personal taste) downright 
ugly.

Imho this looks a whole lot better and can also be very efficiently compiled: 

for d from 10.0 to 5.0 by -0.1 tolerance 0.01
{
print(d)
}


   !!! **
  Important is to see that this “for…”  is in fact
  a convenience solution for  “while” and “repeat” constructs: 
  and thus a totally different beast compared to the   "for in…” ! 
  *
var d = 10.0   
var v = 0.0
let step = 0.1

while d > 5.0 
{ 
print(d)
d -= step
}


The above is a bare minimum “while” equivalent
for the above for-loop, but still tedious to write!

What more can I write to convince? 


*** Please tell me if I am wrong, but: 
I am inclined to think that Functional Programming Minded
Colleagues are trying to push persistently their 
(mathematically correct?)  way of thinking upon Swift, 
thereby ignoring that Swift is and should remain a 
general purpose programming language.


TedvG
www.ravelnotes.com

@Erica,

Erica, as I seem to remember, You wrote somewhere
that Stride is broken, but the "10.0.stride…” example
above works perfectly well in Swift 2.2. playground.

So, what do you regard as wrong with it?
(apart from in some cases needing to specify an 
epsilon(tolerance) value? ) 



  














___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Jeremy Pereira via swift-evolution]

> On 23 Mar 2016, at 15:50, Haravikk  wrote:
> 
>> 
>> 
>> True, but we could have argued the same about the `where` keyword and that 
>> is in existence. :-)
> 
> Speaking of where, why wouldn’t you just do:
> 
>   for eachElement in theIntegerSequence where eachElement < 5 { … }

Apologies, I’m a bit late to the party here, but I’ve been away on holiday.

The problem with `where` is that the loop still consumes all the elements in 
the sequence even in the case where the where clause can never be true again. 
So the above is the same as

for eachElement in theIntegerSequence
{
if eachElement < 5 { … }
}

I think a more useful construct is one that is equivalent to

for eachElement in theIntegerSequence
{
guard eachElement < 5 else { break }
...
}

but as Brent pointed out, putting that guard statement at the top of the loop 
body pretty much answers my main criticism of not having something like for … 
while …



> 
> I think simplified striding is really all we need to cover c-style loop 
> replacement, the only case that can’t be covered is one that uses some kind 
> of variable stride amount, i.e- replacing:
> 
>   var step = 0
>   for (var i = 0; i < 100; i += step) { step += 1 }
> 
> But I think that’s unusual enough that it doesn’t really matter.

And it is covered by using a while loop. 

It makes me smile somewhat that people think Swift is unusual not having a C 
style for loop. When I learned C, it was the _only_ language with such a 
flexible for loop. All of the others (at least those that I came in contact 
with) only had the simple for i = x to y step z style for loop. 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Biala via swift-evolution]

> I get this
> 
> var i:Int = 0
> for i in (0.. {
>    //do something
> }
> 
> 
> 
> for i in (0.. {
>    if something is true
>    {
>        break
>    }
> }
> 
> use i ??
> What is i now :)  

Yes and it is extremly confusing sintax. and you may create such bug 
without even notice just by changing the old C style for cycles. 
I am still new to SWIFT (2 months). Here is what I thing
1. Breaking existing code meens that swift is still in beta and one should 
always think twice before investing in big project.
2. swift has no clear vision of "for" cycles. All cycles resemble "while" cycle 
when compiled to CPU instructions and can be implemented with while loop. 
Pascal had a limited for cycles just for easy enumeration. C on the other hand 
has much more capable for cycles that suited many cases. From what I read there 
is no clear idea about "for" in swift. They have to write down the scenarios 
they want to cover and and offer ONE syntax for them all. Having a different 
syntax for different C scenarios is confusing - better leave the C syntax. 
3. swift has hidden function calls like C# - that affects the code performance 
in an unexpected way. Function calls are expensive in ARM architecture and they 
should be avoided in loops. So this leads to the arrays. Swift is slow beacause 
reading and changing array members is slow and that is what usually is made in 
loops. There should be no hiden function calls there. I may suggest using 
UnsafeMuttablePointer to create a new fast array  class or struct and add it 
into the language for everyone to use.
4. writing many things in one line is BAD in million lines projects. It is 
called "compressed logic" - leads to bugs, and slow code maintenance. Swift 
closers are becoming really messy at this point so some rules against 
compressed logic are needed.
5. There are many great things in swift that I have not seen anywhere else like 
swift functions, interaction with C code, dictionaries and more and more. So I 
have a strong believe in the swift development team .
 

On Thursday, March 24, 2016 5:59 AM, Brent Royal-Gordon 
 wrote:
 

 > I get this
> 
> var i:Int = 0
> for i in (0.. {
>    //do something
> }
> 
> 
> 
> for i in (0.. {
>    if something is true
>    {
>        break
>    }
> }
> 
> use i ??
> What is i now :)  

The outer `i` is 0 because it was never used. The expression `for i in...` 
implicitly declares a new `i`.

-- 
Brent Royal-Gordon
Architechies


  ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Brent Royal-Gordon via swift-evolution]

>> But honestly, other than distaste, I don't see much of a practical issue 
>> with putting an `if` or `guard` on the first line with a `break` in it. That 
>> still clusters the iteration logic at the top of the loop, even if it's not 
>> quite in a single statement.
> 
> True, but we could have argued the same about the `where` keyword and that is 
> in existence. :-)

I believe I've spoken against the `where` clause earlier in this thread, but if 
I didn't, I will now: I don't like it. However, I believe it was added at the 
same time as `case` in the variable slot, and essentially as part of the same 
package of features, so I at least understand where it's coming from.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Brent Royal-Gordon via swift-evolution]

> I get this
> 
> var i:Int = 0
> for i in (0.. {
> //do something
> }
> 
> 
> 
> for i in (0.. {
> if something is true
> {
> break
> }
> }
> 
> use i ??
> What is i now :)  

The outer `i` is 0 because it was never used. The expression `for i in...` 
implicitly declares a new `i`.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Dany St-Amant via swift-evolution]

> Le 23 mars 2016 à 21:59, William Dillon  a écrit :
> 
>> 
>> On Mar 23, 2016, at 6:46 PM, Dany St-Amant via swift-evolution 
>> > wrote:
>> 
>> 
>>> Le 22 mars 2016 à 21:19, William Dillon >> > a écrit :
>>> 
 
 These may be compact, but some programmer may fell that they are not in 
 control: do these "stdlib" seq(), c.filter() pre-calculate all the entries 
 (wasting precious cpu cycle if one break out early)  or are each value 
 dynamically created? Having an explicit legacy loop format gives a feel of 
 control. So something like
 
 for i from 2 to 1_000_000 by 1 where i % 2 != 0 while foundCount < 5 { 
 print(i); foundCount +=1 }
 
 sounds less magical and seems easier to predict than
 
 for i in 2.stride(to:1_000_000, by:1).filter({ $0 % 2 != 0}).prefix(5) { 
 print(i) }
 
 and is still quite readable, even if it mixes for loop, while loop and 
 even simple condition.
 
>>> 
>>> I disagree.  I think the first case is venturing dangerously close to the 
>>> AppleScript “uncanny valley” of human language-like programming verbs where 
>>> I never know the exact words and exact order for things.  The second 
>>> example is right out of any functional programming mold, and I fully 
>>> understand what’s happening, and how to decompose the process to test 
>>> assumptions.  Also, I know how to implement the second case (more or less) 
>>> from scratch, and that’s pretty huge for me.
>>> 
>> 
>> There have been multiple fights over too verbose versus too terse, and on 
>> whether or not making it sound like English. I would agree a verbose syntax 
>> for a mandatory statement is a pain, but the while and where above are 
>> optional. And using them instead of relying on continue or break allow for 
>> code intent to be bit clearer.
>> 
>> Reusing my bad example, without the from/to/by:
>> 
>> for i in 2.stride(to: 1_000_000, by: 1)
>> {
>>  if i % 2 != 0 { continue }
>>  print(i)
>>  foundCount += 1
>>  if foundCount >= 5 { break }
>> }
>> 
>> // Where clause already work in current Swift
>> for i in 2.stride(to: 1_000_000, by: 1)
>> where i % 2 == 0
>> {
>>  print(i)
>>  foundCount += 1
>>  if foundCount >= 5 { break }
>> }
>> 
>> // While do not exist yet in this context
>> for i in 2.stride(to: 1_000_000, by: 1)
>> where i % 2 == 0
>> while foundCount < 5
>> {
>>  print(i)
>>  foundCount += 1
>> }
>> 
> 
> The ‘where’ I can tolerate because there are other examples of such a 
> construct in other parts of the language.  The while part is still 
> problematic, because where have you declared it?  Do you think declaring a 
> variable for that somewhere outside the context of the loop is cleaner than 
> leaving it entirely within that scope then doing a test and break?

Usually when a loop exit early with a break, which would make sense to use with 
the while construct, such loop is followed by a if statement against that 
condition, so it make perfect sense to declare it i the outer scope.

// While do not exist yet in this context
for i in 2.stride(to: 1_000_000, by: 1)
where i % 2 == 0
while foundCount < 5
{
print(i)
foundCount += 1
}

if foundCount != 5
{
print("Sorry not enough element for the quintuplet!.")
// return or throw... we don’t want to continue.
}

Anyway, you cannot declare the above foundCount inside the loop, as it would 
get re-initialized on every iteration.
The for/in/while is not a replacement for some multiple variables loop: 
for(x=0,y=1;…;…) but  for some dual comparison loop (max and early exit): 
for(…;i___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Dany St-Amant via swift-evolution]

> Le 22 mars 2016 à 21:25, Brent Royal-Gordon  a écrit :
> 
>> These may be compact, but some programmer may fell that they are not in 
>> control: do these "stdlib" seq(), c.filter() pre-calculate all the entries 
>> (wasting precious cpu cycle if one break out early)  or are each value 
>> dynamically created? Having an explicit legacy loop format gives a feel of 
>> control. So something like
>> 
>> for i from 2 to 1_000_000 by 1 where i % 2 != 0 while foundCount < 5 { 
>> print(i); foundCount +=1 }
>> 
>> sounds less magical and seems easier to predict than
>> 
>> for i in 2.stride(to:1_000_000, by:1).filter({ $0 % 2 != 0}).prefix(5) { 
>> print(i) }
>> 
>> and is still quite readable, even if it mixes for loop, while loop and even 
>> simple condition.
> 
> First of all, this example sucks. There are *many* ways to write it with 
> existing features which would be more understandable than the pile of random 
> code in your `for` loop. Here are a few:
> 
>   for i in stride(from: 2, to: 1_000_000, by: 1) where i % 2 == 0 {
>   print(i)
>   foundCount += 1
>   if foundCount >= 5 { break }
>   }
> 
>   for i in stride(from: 2, to: 1_000_000, by: 2) {
>   print(i)
>   foundCount += 1
>   if foundCount >= 5 { break }
>   }
> 
>   for i in stride(from: 2, to: 1_000_000, by: 2).prefix(5) {
>   print(i)
>   }
> 
> I know you're trying to illustrate some features you'd like on the `for` 
> loop, but by choosing this example you're not realy challenging your proposal 
> enough for its disadvantages to be illustrated well. For instance, one thing 
> `stride` cannot currently do is apply a step that doesn't involve addition, 
> for instance by multiplying the number. But your `by` keyword suffers from 
> the same problem! To really add anything new, your proposal would have to be 
> vastly more complicated than what you describe here. It's not fair to say 
> "look how much simpler this is" while sweeping the actual complexity under 
> the rug.

I agree with the qualitative you used against my example, but not sure it was 
necessary to say it out loud. The main thing I was trying to illustrate is the 
at glance interpretation and possible "fear" that the for in construct can 
give. The for in, at least to me, strongly suggest pre-allocated array and not 
plain iteration. Forgetting one instant about the legacy for(;;)-from/to/by, if 
Swift had two for loop variants:

for element in array {} // Error if used with stride/range
for element iteratingOver iterator {} // Error if use with array (like one 
generated by filter()

It could help putting my irrational fear away. Yes, we can probably write the 
second as something like: iterationOver(iterator) { closure; } but then you 
cannot use break nor continue.

The example was in no-way a pro-from/to/by, as this format seem limited on 
multiple fronts, but it is the current pre-proposal format suggested by Ted 
based on MatLab syntax.


> 
>> Sorry if the example is a bit dumb as is; but I was too lazy to provide some 
>> nice code instead of the simple print.
>> Can anyone tell if the filter.prefix above is lazy and that each number is 
>> create one by one?
>> The fact that using 1_000_000 above caused my playground to crash, seems to 
>> indicate that the list of number is pre-generated.
> 
> Yes, I can tell you without looking at anything that the second example is 
> greedy. `stride` acts lazy (it returns an instance which, when iterated over, 
> produces the values), but `filter` is greedy unless you explicitly use 
> `lazy`. If you don't know this, you can tell by looking at `filter`'s return 
> type, which is an Array.
> 
> Your "explicit" syntax, on the other hand, seems totally out of control. 
> Where do these features come from? What happens when you find something else 
> you want to do in a loop? Do you invent another keyword and give it a new 
> syntax? This *still* doesn't give you enough flexibility to express a `for` 
> loop which doubles the number; is that going to require a new keyword? How 
> many keywords is it going to take? Is anyone ever going to learn what all 
> these keywords mean? Are you going to have to re-read The Swift Programming 
> Language to decode every moderately complicated `for` loop?

So many questions for a single line of code. I do not think, i have invented 
any keyword, the from/to/by  have been part of the pre-proposal for a while. 
The where can already be used with the for in. The while already exist but is 
not associated with the for in. So by my count, I introduced 0 new keyword, and 
1 new syntax: allowing while to be tagged against a for.

Putting the ‘while’ as part of my example was to cover a common case of for(;;) 
which came to mind where people use two conditions: an array upper bound, and 
an early exit (usually somethingFound). In C, the for (;;) is way too flexible 
and we 

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[William Dillon via swift-evolution]

> On Mar 23, 2016, at 6:46 PM, Dany St-Amant via swift-evolution 
>  wrote:
> 
> 
>> Le 22 mars 2016 à 21:19, William Dillon > > a écrit :
>> 
>>> 
>>> These may be compact, but some programmer may fell that they are not in 
>>> control: do these "stdlib" seq(), c.filter() pre-calculate all the entries 
>>> (wasting precious cpu cycle if one break out early)  or are each value 
>>> dynamically created? Having an explicit legacy loop format gives a feel of 
>>> control. So something like
>>> 
>>> for i from 2 to 1_000_000 by 1 where i % 2 != 0 while foundCount < 5 { 
>>> print(i); foundCount +=1 }
>>> 
>>> sounds less magical and seems easier to predict than
>>> 
>>> for i in 2.stride(to:1_000_000, by:1).filter({ $0 % 2 != 0}).prefix(5) { 
>>> print(i) }
>>> 
>>> and is still quite readable, even if it mixes for loop, while loop and even 
>>> simple condition.
>>> 
>> 
>> I disagree.  I think the first case is venturing dangerously close to the 
>> AppleScript “uncanny valley” of human language-like programming verbs where 
>> I never know the exact words and exact order for things.  The second example 
>> is right out of any functional programming mold, and I fully understand 
>> what’s happening, and how to decompose the process to test assumptions.  
>> Also, I know how to implement the second case (more or less) from scratch, 
>> and that’s pretty huge for me.
>> 
> 
> There have been multiple fights over too verbose versus too terse, and on 
> whether or not making it sound like English. I would agree a verbose syntax 
> for a mandatory statement is a pain, but the while and where above are 
> optional. And using them instead of relying on continue or break allow for 
> code intent to be bit clearer.
> 
> Reusing my bad example, without the from/to/by:
> 
> for i in 2.stride(to: 1_000_000, by: 1)
> {
>   if i % 2 != 0 { continue }
>   print(i)
>   foundCount += 1
>   if foundCount >= 5 { break }
> }
> 
> // Where clause already work in current Swift
> for i in 2.stride(to: 1_000_000, by: 1)
> where i % 2 == 0
> {
>   print(i)
>   foundCount += 1
>   if foundCount >= 5 { break }
> }
> 
> // While do not exist yet in this context
> for i in 2.stride(to: 1_000_000, by: 1)
> where i % 2 == 0
> while foundCount < 5
> {
>   print(i)
>   foundCount += 1
> }
> 

The ‘where’ I can tolerate because there are other examples of such a construct 
in other parts of the language.  The while part is still problematic, because 
where have you declared it?  Do you think declaring a variable for that 
somewhere outside the context of the loop is cleaner than leaving it entirely 
within that scope then doing a test and break?

- Will

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Dany St-Amant via swift-evolution]

> Le 22 mars 2016 à 21:19, William Dillon  a écrit :
> 
>> 
>> These may be compact, but some programmer may fell that they are not in 
>> control: do these "stdlib" seq(), c.filter() pre-calculate all the entries 
>> (wasting precious cpu cycle if one break out early)  or are each value 
>> dynamically created? Having an explicit legacy loop format gives a feel of 
>> control. So something like
>> 
>> for i from 2 to 1_000_000 by 1 where i % 2 != 0 while foundCount < 5 { 
>> print(i); foundCount +=1 }
>> 
>> sounds less magical and seems easier to predict than
>> 
>> for i in 2.stride(to:1_000_000, by:1).filter({ $0 % 2 != 0}).prefix(5) { 
>> print(i) }
>> 
>> and is still quite readable, even if it mixes for loop, while loop and even 
>> simple condition.
>> 
> 
> I disagree.  I think the first case is venturing dangerously close to the 
> AppleScript “uncanny valley” of human language-like programming verbs where I 
> never know the exact words and exact order for things.  The second example is 
> right out of any functional programming mold, and I fully understand what’s 
> happening, and how to decompose the process to test assumptions.  Also, I 
> know how to implement the second case (more or less) from scratch, and that’s 
> pretty huge for me.
> 

There have been multiple fights over too verbose versus too terse, and on 
whether or not making it sound like English. I would agree a verbose syntax for 
a mandatory statement is a pain, but the while and where above are optional. 
And using them instead of relying on continue or break allow for code intent to 
be bit clearer.

Reusing my bad example, without the from/to/by:

for i in 2.stride(to: 1_000_000, by: 1)
{
if i % 2 != 0 { continue }
print(i)
foundCount += 1
if foundCount >= 5 { break }
}

// Where clause already work in current Swift
for i in 2.stride(to: 1_000_000, by: 1)
where i % 2 == 0
{
print(i)
foundCount += 1
if foundCount >= 5 { break }
}

// While do not exist yet in this context
for i in 2.stride(to: 1_000_000, by: 1)
where i % 2 == 0
while foundCount < 5
{
print(i)
foundCount += 1
}

Dany


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Haravikk via swift-evolution]

> On 23 Mar 2016, at 14:55, Jeremy Pereira via swift-evolution 
>  wrote:
> 
> 
>> On 23 Mar 2016, at 11:38, Brent Royal-Gordon  wrote:
>> 
>>> One advantage of the old C style for loop is that everything to do with 
>>> loop control is in one place, usually on one line. There is currently no 
>>> way of doing that for the (quite common) use case of iterating through a 
>>> sequence until a particular condition (other than the end of the sequence) 
>>> is true except by using a break. 
>> 
>> If you can stand using method chains, I believe that role would be filled by 
>> the `takeWhile(_:)` method that Kevin Ballard (IIRC) wants to add to 
>> Sequence. (Although `takeWhile(_:)` would be greedy by default.)
> 
> After writing the last email, I tried adding a method to SequenceType called 
> whileTrue(_:) that did pretty much the same thing. It wrapped a Generator in 
> another custom Generator that ended when the supplied closure returned true 
> and it worked fine. However, the closure had no visibility of the iterator so
> 
>for i in someIntegerSequence.whileTrue({ i < 5 }) { … } 
> 
> was understandably a compiler error. 
> 
>> 
>> But honestly, other than distaste, I don't see much of a practical issue 
>> with putting an `if` or `guard` on the first line with a `break` in it. That 
>> still clusters the iteration logic at the top of the loop, even if it's not 
>> quite in a single statement.
> 
> True, but we could have argued the same about the `where` keyword and that is 
> in existence. :-)

Speaking of where, why wouldn’t you just do:

for eachElement in theIntegerSequence where eachElement < 5 { … }

I think simplified striding is really all we need to cover c-style loop 
replacement, the only case that can’t be covered is one that uses some kind of 
variable stride amount, i.e- replacing:

var step = 0
for (var i = 0; i < 100; i += step) { step += 1 }

But I think that’s unusual enough that it doesn’t really matter.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Biala via swift-evolution]

Some code :
WAS:>var i:Int = 0for (i=0;i>>
Now without C style forafter mechanically repair the code
I get this
var i:Int = 0for i in (0.. wrote:
 

 > One advantage of the old C style for loop is that everything to do with loop 
 > control is in one place, usually on one line. There is currently no way of 
 > doing that for the (quite common) use case of iterating through a sequence 
 > until a particular condition (other than the end of the sequence) is true 
 > except by using a break. 

If you can stand using method chains, I believe that role would be filled by 
the `takeWhile(_:)` method that Kevin Ballard (IIRC) wants to add to Sequence. 
(Although `takeWhile(_:)` would be greedy by default.)

But honestly, other than distaste, I don't see much of a practical issue with 
putting an `if` or `guard` on the first line with a `break` in it. That still 
clusters the iteration logic at the top of the loop, even if it's not quite in 
a single statement.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


  ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Jeremy Pereira via swift-evolution]

> On 23 Mar 2016, at 11:38, Brent Royal-Gordon  wrote:
> 
>> One advantage of the old C style for loop is that everything to do with loop 
>> control is in one place, usually on one line. There is currently no way of 
>> doing that for the (quite common) use case of iterating through a sequence 
>> until a particular condition (other than the end of the sequence) is true 
>> except by using a break. 
> 
> If you can stand using method chains, I believe that role would be filled by 
> the `takeWhile(_:)` method that Kevin Ballard (IIRC) wants to add to 
> Sequence. (Although `takeWhile(_:)` would be greedy by default.)

After writing the last email, I tried adding a method to SequenceType called 
whileTrue(_:) that did pretty much the same thing. It wrapped a Generator in 
another custom Generator that ended when the supplied closure returned true and 
it worked fine. However, the closure had no visibility of the iterator so

for i in someIntegerSequence.whileTrue({ i < 5 }) { … } 

was understandably a compiler error. 

> 
> But honestly, other than distaste, I don't see much of a practical issue with 
> putting an `if` or `guard` on the first line with a `break` in it. That still 
> clusters the iteration logic at the top of the loop, even if it's not quite 
> in a single statement.

True, but we could have argued the same about the `where` keyword and that is 
in existence. :-)


Having said all that, when I converted a Swift 2.1 project with 10s of 
thousands of lines of code to 2.2, I found only two C style for loops, one of 
which could have used the iterator syntax and the other I converted to a while 
loop. The conversion effort was less than it took to write this email.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Brent Royal-Gordon via swift-evolution]

> One advantage of the old C style for loop is that everything to do with loop 
> control is in one place, usually on one line. There is currently no way of 
> doing that for the (quite common) use case of iterating through a sequence 
> until a particular condition (other than the end of the sequence) is true 
> except by using a break. 

If you can stand using method chains, I believe that role would be filled by 
the `takeWhile(_:)` method that Kevin Ballard (IIRC) wants to add to Sequence. 
(Although `takeWhile(_:)` would be greedy by default.)

But honestly, other than distaste, I don't see much of a practical issue with 
putting an `if` or `guard` on the first line with a `break` in it. That still 
clusters the iteration logic at the top of the loop, even if it's not quite in 
a single statement.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Jeremy Pereira via swift-evolution]

> On 23 Mar 2016, at 10:40, Maximilian Hünenberger via swift-evolution 
>  wrote:
> 
> I totally agree with you that the for loop shouldn't be overloaded with 
> keywords. Although a "while" condition could be a reasonable addition since 
> the "breaking" condition is at the top of the for loop not at the bottom. One 
> can benefit from this if the condition is more complex.
> But this should be a separate proposal.

+1 for a while condition. I really hate having to use break to terminate a for 
loop early. In fact, if it were up to me, break (and continue) would not be in 
the language. 

One advantage of the old C style for loop is that everything to do with loop 
control is in one place, usually on one line. There is currently no way of 
doing that for the (quite common) use case of iterating through a sequence 
until a particular condition (other than the end of the sequence) is true 
except by using a break. 

In fact, I’d rather have the while condition than than the existing where 
condition.

> 
> - Maximilian
> 
> Am 23.03.2016 um 02:25 schrieb Brent Royal-Gordon via swift-evolution 
> :
> 
>>> These may be compact, but some programmer may fell that they are not in 
>>> control: do these "stdlib" seq(), c.filter() pre-calculate all the entries 
>>> (wasting precious cpu cycle if one break out early)  or are each value 
>>> dynamically created? Having an explicit legacy loop format gives a feel of 
>>> control. So something like
>>> 
>>> for i from 2 to 1_000_000 by 1 where i % 2 != 0 while foundCount < 5 { 
>>> print(i); foundCount +=1 }
>>> 
>>> sounds less magical and seems easier to predict than
>>> 
>>> for i in 2.stride(to:1_000_000, by:1).filter({ $0 % 2 != 0}).prefix(5) { 
>>> print(i) }
>>> 
>>> and is still quite readable, even if it mixes for loop, while loop and even 
>>> simple condition.
>> 
>> First of all, this example sucks. There are *many* ways to write it with 
>> existing features which would be more understandable than the pile of random 
>> code in your `for` loop. Here are a few:
>> 
>>   for i in stride(from: 2, to: 1_000_000, by: 1) where i % 2 == 0 {
>>   print(i)
>>   foundCount += 1
>>   if foundCount >= 5 { break }
>>   }
>> 
>>   for i in stride(from: 2, to: 1_000_000, by: 2) {
>>   print(i)
>>   foundCount += 1
>>   if foundCount >= 5 { break }
>>   }
>> 
>>   for i in stride(from: 2, to: 1_000_000, by: 2).prefix(5) {
>>   print(i)
>>   }
>> 
>> I know you're trying to illustrate some features you'd like on the `for` 
>> loop, but by choosing this example you're not realy challenging your 
>> proposal enough for its disadvantages to be illustrated well. For instance, 
>> one thing `stride` cannot currently do is apply a step that doesn't involve 
>> addition, for instance by multiplying the number. But your `by` keyword 
>> suffers from the same problem! To really add anything new, your proposal 
>> would have to be vastly more complicated than what you describe here. It's 
>> not fair to say "look how much simpler this is" while sweeping the actual 
>> complexity under the rug.
>> 
>>> Sorry if the example is a bit dumb as is; but I was too lazy to provide 
>>> some nice code instead of the simple print.
>>> Can anyone tell if the filter.prefix above is lazy and that each number is 
>>> create one by one?
>>> The fact that using 1_000_000 above caused my playground to crash, seems to 
>>> indicate that the list of number is pre-generated.
>> 
>> Yes, I can tell you without looking at anything that the second example is 
>> greedy. `stride` acts lazy (it returns an instance which, when iterated 
>> over, produces the values), but `filter` is greedy unless you explicitly use 
>> `lazy`. If you don't know this, you can tell by looking at `filter`'s return 
>> type, which is an Array.
>> 
>> Your "explicit" syntax, on the other hand, seems totally out of control. 
>> Where do these features come from? What happens when you find something else 
>> you want to do in a loop? Do you invent another keyword and give it a new 
>> syntax? This *still* doesn't give you enough flexibility to express a `for` 
>> loop which doubles the number; is that going to require a new keyword? How 
>> many keywords is it going to take? Is anyone ever going to learn what all 
>> these keywords mean? Are you going to have to re-read The Swift Programming 
>> Language to decode every moderately complicated `for` loop?
>> 
>> (And how am I supposed to mentally parse your sea of undifferentiated 
>> alphanumerics? Punctuation in a programming language helps you understand 
>> the role of each part of it; your proposal's lack of punctuation makes it 
>> difficult to read.)
>> 
>> The function/method-based approach requires a little more syntax and a 
>> little more understanding of what's going on. But has huge advantages that I 
>> think you're unfairly ignoring:
>> 
>> * It is simple. The `for` loop itself is 

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Maximilian Hünenberger via swift-evolution]

I totally agree with you that the for loop shouldn't be overloaded with 
keywords. Although a "while" condition could be a reasonable addition since the 
"breaking" condition is at the top of the for loop not at the bottom. One can 
benefit from this if the condition is more complex.
But this should be a separate proposal.

- Maximilian

Am 23.03.2016 um 02:25 schrieb Brent Royal-Gordon via swift-evolution 
:

>> These may be compact, but some programmer may fell that they are not in 
>> control: do these "stdlib" seq(), c.filter() pre-calculate all the entries 
>> (wasting precious cpu cycle if one break out early)  or are each value 
>> dynamically created? Having an explicit legacy loop format gives a feel of 
>> control. So something like
>> 
>> for i from 2 to 1_000_000 by 1 where i % 2 != 0 while foundCount < 5 { 
>> print(i); foundCount +=1 }
>> 
>> sounds less magical and seems easier to predict than
>> 
>> for i in 2.stride(to:1_000_000, by:1).filter({ $0 % 2 != 0}).prefix(5) { 
>> print(i) }
>> 
>> and is still quite readable, even if it mixes for loop, while loop and even 
>> simple condition.
> 
> First of all, this example sucks. There are *many* ways to write it with 
> existing features which would be more understandable than the pile of random 
> code in your `for` loop. Here are a few:
> 
>for i in stride(from: 2, to: 1_000_000, by: 1) where i % 2 == 0 {
>print(i)
>foundCount += 1
>if foundCount >= 5 { break }
>}
> 
>for i in stride(from: 2, to: 1_000_000, by: 2) {
>print(i)
>foundCount += 1
>if foundCount >= 5 { break }
>}
> 
>for i in stride(from: 2, to: 1_000_000, by: 2).prefix(5) {
>print(i)
>}
> 
> I know you're trying to illustrate some features you'd like on the `for` 
> loop, but by choosing this example you're not realy challenging your proposal 
> enough for its disadvantages to be illustrated well. For instance, one thing 
> `stride` cannot currently do is apply a step that doesn't involve addition, 
> for instance by multiplying the number. But your `by` keyword suffers from 
> the same problem! To really add anything new, your proposal would have to be 
> vastly more complicated than what you describe here. It's not fair to say 
> "look how much simpler this is" while sweeping the actual complexity under 
> the rug.
> 
>> Sorry if the example is a bit dumb as is; but I was too lazy to provide some 
>> nice code instead of the simple print.
>> Can anyone tell if the filter.prefix above is lazy and that each number is 
>> create one by one?
>> The fact that using 1_000_000 above caused my playground to crash, seems to 
>> indicate that the list of number is pre-generated.
> 
> Yes, I can tell you without looking at anything that the second example is 
> greedy. `stride` acts lazy (it returns an instance which, when iterated over, 
> produces the values), but `filter` is greedy unless you explicitly use 
> `lazy`. If you don't know this, you can tell by looking at `filter`'s return 
> type, which is an Array.
> 
> Your "explicit" syntax, on the other hand, seems totally out of control. 
> Where do these features come from? What happens when you find something else 
> you want to do in a loop? Do you invent another keyword and give it a new 
> syntax? This *still* doesn't give you enough flexibility to express a `for` 
> loop which doubles the number; is that going to require a new keyword? How 
> many keywords is it going to take? Is anyone ever going to learn what all 
> these keywords mean? Are you going to have to re-read The Swift Programming 
> Language to decode every moderately complicated `for` loop?
> 
> (And how am I supposed to mentally parse your sea of undifferentiated 
> alphanumerics? Punctuation in a programming language helps you understand the 
> role of each part of it; your proposal's lack of punctuation makes it 
> difficult to read.)
> 
> The function/method-based approach requires a little more syntax and a little 
> more understanding of what's going on. But has huge advantages that I think 
> you're unfairly ignoring:
> 
> * It is simple. The `for` loop itself is quite uncomplicated. The only extra 
> features it has are the `case` clause, which can't be easily duplicated in 
> another way, and the `where` clause, which I've honestly never been totally 
> happy with.
> * It is reusable. Calls like `stride`, `filter` and `prefix` can be used even 
> outside a `for` loop.
> * It is extensible. If you need something new, you can add it, and it will be 
> just as accessible as anything the standard library's designers dreamed up.
> * It is documentable. By using functions and methods instead of keywords, 
> it's easier to look up what a particular feature does.
> * It is sustainable. If we have some kind of really specific looping 
> mechanism like you propose, every little feature we want will need a specific 
> design, evolution proposal, and 

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Brent Royal-Gordon via swift-evolution]

> These may be compact, but some programmer may fell that they are not in 
> control: do these "stdlib" seq(), c.filter() pre-calculate all the entries 
> (wasting precious cpu cycle if one break out early)  or are each value 
> dynamically created? Having an explicit legacy loop format gives a feel of 
> control. So something like
> 
> for i from 2 to 1_000_000 by 1 where i % 2 != 0 while foundCount < 5 { 
> print(i); foundCount +=1 }
> 
> sounds less magical and seems easier to predict than
> 
> for i in 2.stride(to:1_000_000, by:1).filter({ $0 % 2 != 0}).prefix(5) { 
> print(i) }
> 
> and is still quite readable, even if it mixes for loop, while loop and even 
> simple condition.

First of all, this example sucks. There are *many* ways to write it with 
existing features which would be more understandable than the pile of random 
code in your `for` loop. Here are a few:

for i in stride(from: 2, to: 1_000_000, by: 1) where i % 2 == 0 {
print(i)
foundCount += 1
if foundCount >= 5 { break }
}

for i in stride(from: 2, to: 1_000_000, by: 2) {
print(i)
foundCount += 1
if foundCount >= 5 { break }
}

for i in stride(from: 2, to: 1_000_000, by: 2).prefix(5) {
print(i)
}

I know you're trying to illustrate some features you'd like on the `for` loop, 
but by choosing this example you're not realy challenging your proposal enough 
for its disadvantages to be illustrated well. For instance, one thing `stride` 
cannot currently do is apply a step that doesn't involve addition, for instance 
by multiplying the number. But your `by` keyword suffers from the same problem! 
To really add anything new, your proposal would have to be vastly more 
complicated than what you describe here. It's not fair to say "look how much 
simpler this is" while sweeping the actual complexity under the rug.

> Sorry if the example is a bit dumb as is; but I was too lazy to provide some 
> nice code instead of the simple print.
> Can anyone tell if the filter.prefix above is lazy and that each number is 
> create one by one?
> The fact that using 1_000_000 above caused my playground to crash, seems to 
> indicate that the list of number is pre-generated.

Yes, I can tell you without looking at anything that the second example is 
greedy. `stride` acts lazy (it returns an instance which, when iterated over, 
produces the values), but `filter` is greedy unless you explicitly use `lazy`. 
If you don't know this, you can tell by looking at `filter`'s return type, 
which is an Array.

Your "explicit" syntax, on the other hand, seems totally out of control. Where 
do these features come from? What happens when you find something else you want 
to do in a loop? Do you invent another keyword and give it a new syntax? This 
*still* doesn't give you enough flexibility to express a `for` loop which 
doubles the number; is that going to require a new keyword? How many keywords 
is it going to take? Is anyone ever going to learn what all these keywords 
mean? Are you going to have to re-read The Swift Programming Language to decode 
every moderately complicated `for` loop?

(And how am I supposed to mentally parse your sea of undifferentiated 
alphanumerics? Punctuation in a programming language helps you understand the 
role of each part of it; your proposal's lack of punctuation makes it difficult 
to read.)

The function/method-based approach requires a little more syntax and a little 
more understanding of what's going on. But has huge advantages that I think 
you're unfairly ignoring:

* It is simple. The `for` loop itself is quite uncomplicated. The only extra 
features it has are the `case` clause, which can't be easily duplicated in 
another way, and the `where` clause, which I've honestly never been totally 
happy with.
* It is reusable. Calls like `stride`, `filter` and `prefix` can be used even 
outside a `for` loop.
* It is extensible. If you need something new, you can add it, and it will be 
just as accessible as anything the standard library's designers dreamed up.
* It is documentable. By using functions and methods instead of keywords, it's 
easier to look up what a particular feature does.
* It is sustainable. If we have some kind of really specific looping mechanism 
like you propose, every little feature we want will need a specific design, 
evolution proposal, and implementation by the compiler team. That is a 
completely unrealistic plan. Not even the C `for` loop took this approach—it 
provided a *general* mechanism for plugging your own logic into a loop.

Ultimately, piling on new keywords every time you think of a tiny variation is 
simply bad language design. Taking this approach would be foolhardy.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[William Dillon via swift-evolution]

> 
> These may be compact, but some programmer may fell that they are not in 
> control: do these "stdlib" seq(), c.filter() pre-calculate all the entries 
> (wasting precious cpu cycle if one break out early)  or are each value 
> dynamically created? Having an explicit legacy loop format gives a feel of 
> control. So something like
> 
> for i from 2 to 1_000_000 by 1 where i % 2 != 0 while foundCount < 5 { 
> print(i); foundCount +=1 }
> 
> sounds less magical and seems easier to predict than
> 
> for i in 2.stride(to:1_000_000, by:1).filter({ $0 % 2 != 0}).prefix(5) { 
> print(i) }
> 
> and is still quite readable, even if it mixes for loop, while loop and even 
> simple condition.
> 

I disagree.  I think the first case is venturing dangerously close to the 
AppleScript “uncanny valley” of human language-like programming verbs where I 
never know the exact words and exact order for things.  The second example is 
right out of any functional programming mold, and I fully understand what’s 
happening, and how to decompose the process to test assumptions.  Also, I know 
how to implement the second case (more or less) from scratch, and that’s pretty 
huge for me.

- Will

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Dany St-Amant via swift-evolution]

> Le 21 mars 2016 à 12:29, Taras Zakharko via swift-evolution 
>  a écrit :
> 
> 
>> On 21 Mar 2016, at 17:05, ted van gaalen > > wrote:
>> 
>> Hello Taras
>> Please take a look here:
>> https://en.m.wikipedia.org/wiki/For_loop 
>> 
>> 
>> More than 30  !  programming languages since 1957 until now, have their 
>> implementation of the for-loop. If it was or is an inferior construct, it 
>> would have disappeared long ago. That alone proves that it is not inferior, 
>> but indeed very useful.
> 
> And how many of them have the C style for(;;) loop? I don’t even know why the 
> article refers to it as the ‘traditional’ for. Its not traditional, its just 
> popular (because it was introduced with C). The traditional for is the one 
> found in Fotran/Pascal etc. as it actually has that explicit ‘loop variable’ 
> semantics. The C for(;;) loop does not have it. 
> 
> And by the way, I was never suggesting that Swift should drop for loops 
> altogether. I am just saying that the iterator-based for loop is more then 
> adequate for any conceivable purpose (see below). The reason why early 
> languages do not use iterator-based loops is because the computers were less 
> advances back then, as was our understanding of compilers and computer 
> science. Iterator-based loops incur a high abstraction cost, which can be 
> completely removed by an optimising compiler nowadays. There is of course the 
> issue with the debug-build performance, but I am sure that this too can be 
> remedied eventually. 
> 
>> 
>> There is imho no longer any need to compare the for... variants any longer 
>> (but of course feel free to do so), because they both serve different 
>> purposes very well. Neither one or the other is inferior! I would protest 
>> with equal energy also when the for...in... was removed, because this would 
>> make iterating with collections cumbersome, e.g. I am now very happy that I 
>> can now iterate through an array, without specifying start, length and where 
>> we are.. 
> 
> I do not think it is appropriate to think about these constructions in terms 
> of inferior/superior. The fact is that the traditional for loop (iterating 
> trough some numbers) is a strict subset of iterator-based loops. 
> Iterator-based loops can do all things that traditional for loops do and then 
> some more. Which make the traditional loop unnecessary. Again, I dislike the 
> C-style for(;;) loop because it has its own, extended semantics which makes 
> it a hybrid between a for-loop and a while loop. 
> 
> To reiterate, I don’t see the point in having multiple distinct syntaxes for 
> loops when the same thing can be accomplished (and often more compactly so) 
> using the iterator loop. This is just shuffling the syntax around, for no win 
> or reason I can reasonably see. For instance, what you suggest below can be 
> easily done with iterators (and its how Python, R and many other languages do 
> it):
> 
> for i in seq(f, t, by:b, while: w) { }
> for i in c.filter(condition) { }

These may be compact, but some programmer may fell that they are not in 
control: do these "stdlib" seq(), c.filter() pre-calculate all the entries 
(wasting precious cpu cycle if one break out early)  or are each value 
dynamically created? Having an explicit legacy loop format gives a feel of 
control. So something like

for i from 2 to 1_000_000 by 1 where i % 2 != 0 while foundCount < 5 { 
print(i); foundCount +=1 }

sounds less magical and seems easier to predict than

for i in 2.stride(to:1_000_000, by:1).filter({ $0 % 2 != 0}).prefix(5) { 
print(i) }

and is still quite readable, even if it mixes for loop, while loop and even 
simple condition.

Sorry if the example is a bit dumb as is; but I was too lazy to provide some 
nice code instead of the simple print.
Can anyone tell if the filter.prefix above is lazy and that each number is 
create one by one?
The fact that using 1_000_000 above caused my playground to crash, seems to 
indicate that the list of number is pre-generated.

Dany

> Furthermore, with iterator based loops you are free to extend your for loop 
> as your demands change, to produce shorter, more efficient and safer code 
> (see my example with matrix index iteration in the previous mail). 
> 
> — Taras
> 
> 
> 
> 
>> 
>> Concerning my intended proposal for a good alternative for the classicsl 
>> for-loop, I am currently in favor of very much something like this version, 
>> as it is implemented in Maple:
>>   ---start copy from wkpd page---
>> 
>>> Maple has two forms of for-loop, one for iterating of a range of values, 
>>> and the other for iterating over the contents of a container. The value 
>>> range form is as follows:
>>> 
>>> for i from f by b to t while w do # loop body od;
>>> All parts except do and od are optional. The for i part, if present, 

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Jonathan Tang via swift-evolution]

On Mon, Mar 21, 2016 at 9:05 AM, ted van gaalen via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Taras
> Please take a look here:
> https://en.m.wikipedia.org/wiki/For_loop
>
> More than 30  !  programming languages since 1957 until now, have their
> implementation of the for-loop. If it was or is an inferior construct, it
> would have disappeared long ago. That alone proves that it is not inferior,
> but indeed very useful.
>
>
FWIW, a number of recent programming languages don't support it anymore.
Python, Ruby, and Rust all support the iterable form only, with a Range
object to represent a sequence of numbers.  It *is* disappearing, but it
takes 10+ years for a new programming language to get serious adoption, so
what's filtering its way down to mainstream programming is stuff that was
invented 20 years ago and played with by early-adopters 10 years ago.


> There is imho no longer any need to compare the for... variants any longer
> (but of course feel free to do so), because they both serve different
> purposes very well. Neither one or the other is inferior! I would protest
> with equal energy also when the for...in... was removed, because this would
> make iterating with collections cumbersome, e.g. I am now very happy that I
> can now iterate through an array, without specifying start, length and
> where we are..
>
> Concerning my intended proposal for a good alternative for the classicsl
> for-loop, I am currently in favor of very much something like this version,
> as it is implemented in Maple:
>   ---start copy from wkpd page---
>
> Maple has two forms of for-loop, one for iterating of a range of values,
> and the other for iterating over the contents of a container. The value
> range form is as follows:
>
> *for* *i* *from* *f* *by* *b* *to* *t* *while* *w* *do*
> *# loop body**od*;
>
> All parts except *do* and *od* are optional. The *for* *i* part, if
> present, must come first. The remaining parts (*from* *f*, *by* *b*, *to*
> *t*, *while* *w*) can appear in any order.
>
> Iterating over a container is done using this form of loop:
>
> *for* *e* *in* *c* *while* *w* *do*
> *# loop body**od*;
>
> The *in* *c* clause specifies the container, which may be a list, set,
> sum, product, unevaluated function, array, or an object implementing an
> iterator.
>
> A for-loop may be terminated by *od*, *end*, or *end do*.
>
> --end
> copy---
> ( in the above example replace "do" and "od" by { } )
> Maple has two forms of for-loop, one for iterating of a range of values,
> and the other for iterating over the contents of a container.
> In Maple, which by the way is a very advanced programming language for
> mathematicians ( i am not), both variants are available and co-exist
> independently, which is exactly my point!  So again, it is not replacing or
> even changing the for-in as it is now available in Swift, both versions
> should be available. (This would still be the case if the for ;; had not
> been removed in the first place)
> To get back to the Maple for-loop implementation, in Swift I'd drop the
> "while" extension.
> To summarize:
>
> I would like to see in Swift:
>
>  for v from v1 to v2 by v3  {...}
>
> for numerical values Int, Double, Float...
> The "by" clause would be optional: when omitted, it should
> default to 1 for integers and 1.0 for floating point values.
>
> The loop variable ("v" here) cannot be altered in the loop.
> The loop can exited with the "break" statement.
> Use "continue" to directly go to the next iteration( if any)
> ("break" and "continue" functional as it is now)
>
>
> Examples:
>  for v from 0.5 to 30.0 by 0.3
>  for v from 0 to 100 by 5
>  for v from 12.0 to -10.0 by -2
>
> Imho, this is super clean and very readable, Why would anyone have
> objections against it? Also the compiler can optimize this construct very
> easely.
> Yes, the classical for ;; had more options, but are they still needed?
>
>
Curious, would you have any objections if 'by' were a method on ranges,
which already exist in Swift?

for v in 0.5...30.0.by(0.3)
for v in 0...100.by(5)
for v in 12.0...-10.0.by(-2)

The advantage of using range objects instead of special syntax is that then
they're composable with all functions that operate on iterables.  You can,
for example get all primes from 0 to 100 with 0...100.filter(isPrime), or
retrieve the last 5 with such elements with
0...100.filter(isPrime).suffix(5).

I also liked the idea Brent proposed up-thread of having stride() take a
by: parameter that could be an arbitrary function of the last element.
That's very similar to 'unfold' in Haskell, which turns out to be very
useful for constructing arbitrary sequences in a memory-efficient way.


> Note that we also have discussed the floating point number tolerance
> problem previously.
> the for ... from ... to ... by ... could therefore for 

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Taras Zakharko via swift-evolution]

> On 21 Mar 2016, at 17:05, ted van gaalen  wrote:
> 
> Hello Taras
> Please take a look here:
> https://en.m.wikipedia.org/wiki/For_loop 
> 
> 
> More than 30  !  programming languages since 1957 until now, have their 
> implementation of the for-loop. If it was or is an inferior construct, it 
> would have disappeared long ago. That alone proves that it is not inferior, 
> but indeed very useful.

And how many of them have the C style for(;;) loop? I don’t even know why the 
article refers to it as the ‘traditional’ for. Its not traditional, its just 
popular (because it was introduced with C). The traditional for is the one 
found in Fotran/Pascal etc. as it actually has that explicit ‘loop variable’ 
semantics. The C for(;;) loop does not have it. 

And by the way, I was never suggesting that Swift should drop for loops 
altogether. I am just saying that the iterator-based for loop is more then 
adequate for any conceivable purpose (see below). The reason why early 
languages do not use iterator-based loops is because the computers were less 
advances back then, as was our understanding of compilers and computer science. 
Iterator-based loops incur a high abstraction cost, which can be completely 
removed by an optimising compiler nowadays. There is of course the issue with 
the debug-build performance, but I am sure that this too can be remedied 
eventually. 

> 
> There is imho no longer any need to compare the for... variants any longer 
> (but of course feel free to do so), because they both serve different 
> purposes very well. Neither one or the other is inferior! I would protest 
> with equal energy also when the for...in... was removed, because this would 
> make iterating with collections cumbersome, e.g. I am now very happy that I 
> can now iterate through an array, without specifying start, length and where 
> we are.. 

I do not think it is appropriate to think about these constructions in terms of 
inferior/superior. The fact is that the traditional for loop (iterating trough 
some numbers) is a strict subset of iterator-based loops. Iterator-based loops 
can do all things that traditional for loops do and then some more. Which make 
the traditional loop unnecessary. Again, I dislike the C-style for(;;) loop 
because it has its own, extended semantics which makes it a hybrid between a 
for-loop and a while loop. 

To reiterate, I don’t see the point in having multiple distinct syntaxes for 
loops when the same thing can be accomplished (and often more compactly so) 
using the iterator loop. This is just shuffling the syntax around, for no win 
or reason I can reasonably see. For instance, what you suggest below can be 
easily done with iterators (and its how Python, R and many other languages do 
it):

for i in seq(f, t, by:b, while: w) { }
for i in c.filter(condition) { }

etc.

Furthermore, with iterator based loops you are free to extend your for loop as 
your demands change, to produce shorter, more efficient and safer code (see my 
example with matrix index iteration in the previous mail). 

— Taras




> 
> Concerning my intended proposal for a good alternative for the classicsl 
> for-loop, I am currently in favor of very much something like this version, 
> as it is implemented in Maple:
>   ---start copy from wkpd page---
> 
>> Maple has two forms of for-loop, one for iterating of a range of values, and 
>> the other for iterating over the contents of a container. The value range 
>> form is as follows:
>> 
>> for i from f by b to t while w do # loop body od;
>> All parts except do and od are optional. The for i part, if present, must 
>> come first. The remaining parts (from f, by b, to t, while w) can appear in 
>> any order.
>> 
>> Iterating over a container is done using this form of loop:
>> 
>> for e in c while w do # loop body od;
>> The in c clause specifies the container, which may be a list, set, sum, 
>> product, unevaluated function, array, or an object implementing an iterator.
>> 
>> A for-loop may be terminated by od, end, or end do.
>> 
> --end 
> copy---
> 
> ( in the above example replace "do" and "od" by { } )
> Maple has two forms of for-loop, one for iterating of a range of values, 
> and the other for iterating over the contents of a container.
> In Maple, which by the way is a very advanced programming language for 
> mathematicians ( i am not), both variants are available and co-exist 
> independently, which is exactly my point!  So again, it is not replacing or 
> even changing the for-in as it is now available in Swift, both versions 
> should be available. (This would still be the case if the for ;; had not been 
> removed in the first place)
> To get back to the Maple for-loop implementation, in Swift I'd drop the 
> "while" extension.
> To summarize:
> 
> I would like to see in 

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Taras Zakharko via swift-evolution]

To be honest, I have difficulty understanding the premise of this discussion. I 
have always found the C-style  for(;;) loop an awkward construct, because it is 
essentially just an alternative form of writing a general-purpose while loop.  
It is perfectly reasonable to restrict the for construct to, well, ‘for’ 
contexts: iterating through a sequence of items. If you need something more 
complex, either write your own iterator or use a general-purpose while loop.  

As discussed previously, an optimising compiler generates the same machine code 
whether you are using an iterator abstraction or low-level coding. Besides, the 
for .. in .. construct potentially offers more potential for optimisation, 
because it makes the counter variable as well as the semantics of the entire 
loop more explicit (a for(;;) can contain arbitrary stuff). Talking about 
numerical algorithms: this is something I can’t understand at all. I have been 
working with numerical algorithms in Python and R for years, and I have never 
ever missed the C-style for loop. These languages offer convenient functions 
for generating iterable sequences, which are more readable and also represent 
the loop  semantics much better then the for(;;;). Not to mention that the 
iterator pattern allows you to write simpler and more maintainable code. 
Imagine iterating through a sparse matrix or something. With a proper iterator 
pattern you just do:

for (i,j,k) in matrix.indices {

}

With a for(;;) loop you’l probably end up writing a nested construct of quite 
some complexity. 
 
Swift could certainly use some improvements to its iterators (for example 
something like Python generator expressions might be useful), but that is a 
different topic.  

To sum it up:
- for(;;) is an awkward construct which is closer to a while loop than an 
actual sequence iterator pattern (that it should be)
- a proper iterator pattern is more convenient, more readable and offers the 
same performance
- numerical code does not need a for(;;) construct, in fact, using the proper 
iterator pattern makes writing numeric code easier, not more difficult, because 
you can abstract away some common processing/aggregating steps easily, and 
without any drawback
- we should think about how to improve the iterators offered by Swift standard 
library, not go back to an inferior construction

— Taras



> On 21 Mar 2016, at 12:37, Greg Parker via swift-evolution 
>  wrote:
> 
>> 
>> On Mar 19, 2016, at 12:46 AM, Dmitri Gribenko via swift-evolution 
>>  wrote:
>> 
>> Hi Ted,
>> 
>> Thank you for starting this thread.  I agree that removing the C-style
>> for loop has degraded the readability and clarity of some of numerics
>> code.
>> 
>> In the feedback to SE-0007 many people have said that they can convert
>> their code to for-in loops, but I think this actually means that in
>> code that is typically written in Swift today, loops primarily operate
>> on sequences and collections.  It means that numerics is a domain that
>> not many people work in.  But it is a very important domain
>> nevertheless, and clarity for numerics code matters at least as much
>> as it does everywhere else.
>> 
>> I think one way to approach this discussion would be to present
>> multiple concrete code samples that contain C-style for loops and are
>> awkward to write without them.  We can then try looking for patterns,
>> generalize and simplify, and discuss possible solutions.
> 
> Let me emphasize this more strongly. *Concrete*, *real-world* examples are 
> quite likely the only way that you are going to get `for(;;)` back or get any 
> sort of semantically-similar syntactically-different replacement.
> 
> There have been lots of suggestions. None of them are perfect. If we assume 
> that there is in fact no perfect solution then the only way to proceed is to 
> provide sufficient justification for some imperfect solution.
> 
> I'm still waiting for something like this: "We ported our code to Swift 3. 
> Here are 5 reasonable-looking for(;;) loop shapes from 150 call sites, and 
> here are their ugly-looking rewrites."
> 
> (Personally I think removing for(;;) without direct replacement was too 
> aggressive. That view lost. Now its advocates will need to do more work to 
> upend the status quo.)
> 
> 
> -- 
> Greg Parker gpar...@apple.com  Runtime 
> Wrangler
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Jonathan Hull via swift-evolution]

I would also like to see some real world use cases from numerics packages.  
This may be something we can solve by providing a series of customizable 
generators.  Stride might work for a subset of use cases, but I don’t think we 
should try to shoehorn everything into it.

I have generally been using map when I need an arbitrary function:

for i in (1…10).map({$0 ** 2})

It may not be the most efficient, but I have also used where:

for i in 1…10 where i % 3 != 0


Having to put the ( ) around the range does lessen the readability a bit, but I 
think the following is reasonable:

for i in (1…10).by(2)

You could argue to make a new form of for-in-by which only operates on ranges, 
but not sure it is worth the complexity:

for i in 1…10 by 2


What about just providing a generator which has exactly the same semantics as 
the for;; loop had?  I am bad at naming things, so feel free to mentally 
substitute a better name:

func Loop(start:T, end: @autoclosure (T)->bool, step: @autoclosure 
(T)->T) -> GeneratorOf

Which would be used like:

for i in Loop(start:0, end: $0 < 10, step: $0 + 1)

Ack… I just realized @autoclosure doesn’t work when you have a parameter. Is 
there a particular reason for that?  Without @autoclosure it would be the much 
less pretty:

for i in Loop(start:0, end: {$0 < 10}, step: {$0 + 1})


One last option would be to supply bounds instead of a closure and a few 
special cases:

func Loop(start:T, bounds: Range, step: (T)->T) -> GeneratorOf
func Loop(start:Int, bounds:Range, step:Int) -> GeneratorOf
func Loop(start:Double, bounds: Range, step:Double) -> 
GeneratorOf

for i in Loop(start: 0, bounds: 0…10, step: 2)

The special cases could easily optimize (by returning a different generator) so 
only the upper/lower bound has to be checked in the range based on the sign of 
the step.

Thanks,
Jon
Note: All code written in Mail.app, so please excuse any bugs

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Brent Royal-Gordon via swift-evolution]

> A simple example might be:   for (altitude = 0.1; altitude < 10e6; altitude 
> =* 10.0) { . . . }

Conceptually, this could be represented as a variant of `stride` which took a 
unary function for its `by` parameter:

for altitude in stride(from: 0.1, to: 10e6, by: { $0 * 10 }) {
...
}

There are a couple of features which could in theory clean this syntax up a 
bit, but they have limitations that prevent it:

* You can't use trailing closure syntax in a statement like `for` or `if`; the 
trailing closure is treated as the body of the statement.
* You can't use @autoclosure for an expression which has a parameter.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Tino Heth via swift-evolution]

Imho the syntax of the deprecated for-loop was no good fit for Swift, but I've 
read several rumors about inferior performance of the alternatives…. so, as a 
basis for further discussion, I'd like to see some reliable numbers:
I expect that every loop can be expressed in Swift 3 with identical runtime and 
memory characteristics, but I'm not sure if this can be achieved with for-in, 
instead of a more complicated transformation that uses while.

Arguing about syntax is always subjective, but it's hard to justify the 
complete removal of the classic for-loop if the "modern" constructs can't 
compete with it.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Gavin Eadie via swift-evolution]

addendum:  my example was discussed at


https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000488.html
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Patrick Gili via swift-evolution]

I understand this. I am looking forward to see what Ted proposes.

-Patrick

> On Mar 19, 2016, at 2:31 PM, Ross O'Brien  wrote:
> 
> But the discussion is no longer about 'do we really need to take this feature 
> out?'. The feature is already out. It's deprecated in Swift 2.2. The 
> discussion is 'is there a compelling reason to put it back in again?'.
> 
> We still have for-in loops. We still have repeat while. We still have 
> forEach. Iteration isn't going anywhere; it just doesn't have this peculiar 
> semi-colon structure any more. It's a confusing structure for beginning 
> programmers to learn in the first place, and Swift doesn't use semi-colons so 
> much.
> 
> On Sat, Mar 19, 2016 at 6:06 PM, Patrick Gili via swift-evolution 
> > wrote:
> 
>> On Mar 18, 2016, at 7:19 PM, Ted F.A. van Gaalen > > wrote:
>> 
>> On Chris’s advice, I’ve spawned this into a new discussion topic, for which 
>> the base could be
>> part of what I wrote in relation to SE-0007. 
>> 
>> 
>> Hello Patrick
>> as I wrote: 
>> As a result of removing the classical for loop it is to be expected that lot 
>> of people might consider thinking twice about switching to Swift, If they 
>> have to live without (or cumbersome work around) language elements that have 
>> proven to be very useful for at least a few decades...
> 
> There are two groups of people to consider:
> 
> 1) OS X and iOS developers; this group is stuck with whatever the language 
> brings them, for good or bad. If this group of people doesn't like a decision 
> made by the community, they can grumble about it for awhile, suck in a deep 
> breath, and move on.
> 
> 2) Others; this group may be considering using Swift to develop software on 
> other platforms and in other environments. If this group of people doesn't 
> like a decision made by the community, they may think twice and it could 
> significantly impact the uptake by this group of developers. I think it is 
> wise that the community lubricate the transition to Swift as much as possible 
> for this group of developers. I ask if leaving this kind of syntax in the 
> language is so bad? Does it fall in the same category as removing function 
> currying? My gut tells me not, but I could be wrong.
> 
>> 
>> I also find it of the most importance to keep Swift accessible for all kinds 
>> of programmers
>> from starters to academic. 
>> 
>> Graig Federighi said 
>> We think it should be everywhere and used by everyone.
>> 
>> 
>> I subscribe to that.
>> 
>> 
>> -TedvG
>> 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Ross O'Brien via swift-evolution]

But the discussion is no longer about 'do we really need to take this
feature out?'. The feature is already out. It's deprecated in Swift 2.2.
The discussion is 'is there a compelling reason to put it back in again?'.

We still have for-in loops. We still have repeat while. We still have
forEach. Iteration isn't going anywhere; it just doesn't have this peculiar
semi-colon structure any more. It's a confusing structure for beginning
programmers to learn in the first place, and Swift doesn't use semi-colons
so much.

On Sat, Mar 19, 2016 at 6:06 PM, Patrick Gili via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 18, 2016, at 7:19 PM, Ted F.A. van Gaalen 
> wrote:
>
> On Chris’s advice, I’ve spawned this into a new discussion topic, for
> which the base could be
> part of what I wrote in relation to SE-0007.
>
>
> Hello Patrick
> as I wrote:
>
> As a result of removing the classical for loop it is to be expected that
> lot of people might consider thinking twice about switching to Swift, If
> they have to live without (or cumbersome work around) language elements
> that have proven to be very useful for at least a few decades...
>
>
> There are two groups of people to consider:
>
> 1) OS X and iOS developers; this group is stuck with whatever the language
> brings them, for good or bad. If this group of people doesn't like a
> decision made by the community, they can grumble about it for awhile, suck
> in a deep breath, and move on.
>
> 2) Others; this group may be considering using Swift to develop software
> on other platforms and in other environments. If this group of people
> doesn't like a decision made by the community, they may think twice and it
> could significantly impact the uptake by this group of developers. I think
> it is wise that the community lubricate the transition to Swift as much as
> possible for this group of developers. I ask if leaving this kind of syntax
> in the language is so bad? Does it fall in the same category as removing
> function currying? My gut tells me not, but I could be wrong.
>
>
> I also find it of the most importance to keep Swift accessible for all
> kinds of programmers
> from starters to academic.
>
> Graig Federighi said
> *We think it should be everywhere and used by everyone.*
>
>
> I subscribe to that.
>
>
> -TedvG
>
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Patrick Gili via swift-evolution]

> On Mar 18, 2016, at 7:19 PM, Ted F.A. van Gaalen  
> wrote:
> 
> On Chris’s advice, I’ve spawned this into a new discussion topic, for which 
> the base could be
> part of what I wrote in relation to SE-0007. 
> 
> 
> Hello Patrick
> as I wrote: 
> As a result of removing the classical for loop it is to be expected that lot 
> of people might consider thinking twice about switching to Swift, If they 
> have to live without (or cumbersome work around) language elements that have 
> proven to be very useful for at least a few decades...

There are two groups of people to consider:

1) OS X and iOS developers; this group is stuck with whatever the language 
brings them, for good or bad. If this group of people doesn't like a decision 
made by the community, they can grumble about it for awhile, suck in a deep 
breath, and move on.

2) Others; this group may be considering using Swift to develop software on 
other platforms and in other environments. If this group of people doesn't like 
a decision made by the community, they may think twice and it could 
significantly impact the uptake by this group of developers. I think it is wise 
that the community lubricate the transition to Swift as much as possible for 
this group of developers. I ask if leaving this kind of syntax in the language 
is so bad? Does it fall in the same category as removing function currying? My 
gut tells me not, but I could be wrong.

> 
> I also find it of the most importance to keep Swift accessible for all kinds 
> of programmers
> from starters to academic. 
> 
> Graig Federighi said 
> We think it should be everywhere and used by everyone.
> 
> 
> I subscribe to that.
> 
> 
> -TedvG
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Paul Ossenbruggen via swift-evolution]

I guess I am not in the forloopian camp. I spend far too much time, converting 
for i = 0; i < 4; i++) into something more modern like iterating over 
containers. If it is in the language, people will use it, not having it there 
makes people think about better ways of doing things rather than relying on 
muscle memory. I know it is a barrier for some but other languages such as 
Python don’t support this construct and no one will deny that Python is heavily 
used in numerics. 

- Paul

> On Mar 19, 2016, at 1:28 AM, ted van gaalen via swift-evolution 
>  wrote:
> 
> Yes, thank you Dmitri, I think so too.
> Will come back to this later.
> TedvG
> 
> 
> 
> ted van gaalen
> 
> On 19 Mar 2016, at 08:46, Dmitri Gribenko  > wrote:
> 
>> Hi Ted,
>> 
>> Thank you for starting this thread.  I agree that removing the C-style
>> for loop has degraded the readability and clarity of some of numerics
>> code.
>> 
>> In the feedback to SE-0007 many people have said that they can convert
>> their code to for-in loops, but I think this actually means that in
>> code that is typically written in Swift today, loops primarily operate
>> on sequences and collections.  It means that numerics is a domain that
>> not many people work in.  But it is a very important domain
>> nevertheless, and clarity for numerics code matters at least as much
>> as it does everywhere else.
>> 
>> I think one way to approach this discussion would be to present
>> multiple concrete code samples that contain C-style for loops and are
>> awkward to write without them.  We can then try looking for patterns,
>> generalize and simplify, and discuss possible solutions.
>> 
>> Dmitri
>> 
>> -- 
>> main(i,j){for(i=2;;i++){for(j=2;j> (j){printf("%d\n",i);}}} /*Dmitri Gribenko > >*/
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[ted van gaalen via swift-evolution]

Yes, thank you Dmitri, I think so too.
Will come back to this later.
TedvG



ted van gaalen

> On 19 Mar 2016, at 08:46, Dmitri Gribenko  wrote:
> 
> Hi Ted,
> 
> Thank you for starting this thread.  I agree that removing the C-style
> for loop has degraded the readability and clarity of some of numerics
> code.
> 
> In the feedback to SE-0007 many people have said that they can convert
> their code to for-in loops, but I think this actually means that in
> code that is typically written in Swift today, loops primarily operate
> on sequences and collections.  It means that numerics is a domain that
> not many people work in.  But it is a very important domain
> nevertheless, and clarity for numerics code matters at least as much
> as it does everywhere else.
> 
> I think one way to approach this discussion would be to present
> multiple concrete code samples that contain C-style for loops and are
> awkward to write without them.  We can then try looking for patterns,
> generalize and simplify, and discuss possible solutions.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[ted van gaalen via swift-evolution]

Hello T.J.
It will be an addition, not a change. The for-  statement I will bring forward 
does not change the existing for-in... at all or any other language element.

-TedvG


> On 19 Mar 2016, at 00:55, T.J. Usiyan  wrote:
> 
> Please… *please* let this lie. 
> 
> I understand that it will likely cause some specific cases to become more 
> difficult but, on balance, it was a simplifying change. The syntax that we do 
> have is clearer to those unfamiliar with programming idioms from other 
> languages and people *are* familiar with other programming languages have the 
> tools to construct whatever functionality they feel is missing from the 
> provided tools.
> 
> TJ
> 
>> On Fri, Mar 18, 2016 at 5:19 PM, Ted F.A. van Gaalen via swift-evolution 
>>  wrote:
>> On Chris’s advice, I’ve spawned this into a new discussion topic, for which 
>> the base could be
>> part of what I wrote in relation to SE-0007. 
>> 
>> 
>> Hello Patrick
>> as I wrote: 
>> As a result of removing the classical for loop it is to be expected that lot 
>> of people might consider thinking twice about switching to Swift, If they 
>> have to live without (or cumbersome work around) language elements that have 
>> proven to be very useful for at least a few decades...
>> 
>> I also find it of the most importance to keep Swift accessible for all kinds 
>> of programmers
>> from starters to academic. 
>> 
>> Graig Federighi said 
>> We think it should be everywhere and used by everyone.
>> 
>> 
>> I subscribe to that.
>> 
>> 
>> -TedvG
>> 
>> 
>> 
>> 
>> 
>>> On 18.03.2016, at 22:04, Patrick Gili  wrote:
>>> 
>>> Hi Ted,
>>> 
>>> I don't think many of us that are active on this mailing list had the 
>>> opportunity to provide feedback on this proposal review. I very much agree 
>>> with you on many points that you bring up below. I have spent a lot of time 
>>> scratching my head wondering why it was so important to remove certain 
>>> syntax from Swift, such as C-style loops, unary increment, and unary 
>>> decrement. Leaving them there increases compatibility of C code with Swift, 
>>> and leaving them there keeps them opt-in. If you don't want to use it, you 
>>> don't have to. However, the changes definitely force developers to use 
>>> newer syntax, which runs contrary to the "opt-in philosophy" that the core 
>>> team has impressed on the community.
>>> 
>>> I'm going to play devil's advocate though. Will the tools for Swift 3 
>>> automatically make the necessary changes to source to comply with the new 
>>> syntax? If so, is it so bad? I've been using the C language and all of its 
>>> variants for more than 32 years. Hence, it is easier on my eyes and brain 
>>> if there is some compatibility there. Personally, I think leaving this 
>>> syntax in the language eases migration. Although, I've been learning so 
>>> many new languages over the last decade that it seems to matter less with 
>>> time. However, I can't seem for the millions of developers that write code 
>>> for OS X and iOS.
>>> 
>>> Cheers,
>>> -Patrick
>>> 
 On Mar 18, 2016, at 4:28 PM, Ted F.A. van Gaalen via swift-evolution 
  wrote:
 
 As most colleagues (that's what I think you all are, spanning two 
 generations :o) 
 might have noticed, I am not exactly happy with the removal of the 
 classical 
 for-loop   ( for ;; )  but the damage has been done, so I will soon 
 present a proposal for a better alternative. Working on it.
 I find this matter very important.
 
 I do not agree with the for-loop removal proposal authored by Erica Sadun,
 
 Important: 
 I would like to emphasize again that what I write is not intended 
 personally. 
 
 Also I realize that I am a bit late on this subject, but that is because I 
 was not here back then.
 
 I wil go through it point by point and try to explain why IMHO I think 
 this is not a good proposal. 
 -
 
 Evaluating proposal SE-0007
 Remove C-style for-loops with conditions and incrementers
•   Proposal:   •   Author(s): Erica Sadun
 
 
 
 "The C-style for-loop appears to be a mechanical carry-over from C rather 
 than a genuinely Swift-specific construct."
 
 Could you explain to me why what, in your view, is 
 -  a "genuinely Swift-specific construct” ?
 - "not very Swift-like" ?  
 - "Swift-typical” ?
 
 "It is rarely used  and not very Swift-like."
 
 This is definitely not true. 
 The classical for loop is one of the most frequently used language 
 constructs in most programming languages.
 
 
 "More Swift-typical construction is already available with for-in 
 statements and stride." 
 
 Except for collections, these are inconvenient, cumbersome and inefficient 
  "work 

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[T.J. Usiyan via swift-evolution]

Please… *please* let this lie.

I understand that it will likely cause some specific cases to become more
difficult but, on balance, it was a simplifying change. The syntax that we
do have is clearer to those unfamiliar with programming idioms from other
languages and people *are* familiar with other programming languages have
the tools to construct whatever functionality they feel is missing from the
provided tools.

TJ

On Fri, Mar 18, 2016 at 5:19 PM, Ted F.A. van Gaalen via swift-evolution <
swift-evolution@swift.org> wrote:

> On Chris’s advice, I’ve spawned this into a new discussion topic, for
> which the base could be
> part of what I wrote in relation to SE-0007.
>
>
> Hello Patrick
> as I wrote:
>
> As a result of removing the classical for loop it is to be expected that
> lot of people might consider thinking twice about switching to Swift, If
> they have to live without (or cumbersome work around) language elements
> that have proven to be very useful for at least a few decades...
>
> I also find it of the most importance to keep Swift accessible for all
> kinds of programmers
> from starters to academic.
>
> Graig Federighi said
> *We think it should be everywhere and used by everyone.*
>
>
> I subscribe to that.
>
>
> -TedvG
>
>
>
>
>
> On 18.03.2016, at 22:04, Patrick Gili 
> wrote:
>
> Hi Ted,
>
> I don't think many of us that are active on this mailing list had the
> opportunity to provide feedback on this proposal review. I very much agree
> with you on many points that you bring up below. I have spent a lot of time
> scratching my head wondering why it was so important to remove certain
> syntax from Swift, such as C-style loops, unary increment, and unary
> decrement. Leaving them there increases compatibility of C code with Swift,
> and leaving them there keeps them opt-in. If you don't want to use it, you
> don't have to. However, the changes definitely force developers to use
> newer syntax, which runs contrary to the "opt-in philosophy" that the core
> team has impressed on the community.
>
> I'm going to play devil's advocate though. Will the tools for Swift 3
> automatically make the necessary changes to source to comply with the new
> syntax? If so, is it so bad? I've been using the C language and all of its
> variants for more than 32 years. Hence, it is easier on my eyes and brain
> if there is some compatibility there. Personally, I think leaving this
> syntax in the language eases migration. Although, I've been learning so
> many new languages over the last decade that it seems to matter less with
> time. However, I can't seem for the millions of developers that write code
> for OS X and iOS.
>
> Cheers,
> -Patrick
>
> On Mar 18, 2016, at 4:28 PM, Ted F.A. van Gaalen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> As most colleagues (that's what I think you all are, spanning two
> generations :o)
> might have noticed, I am not exactly happy with the removal of the
> classical
> for-loop   ( for ;; )  but the damage has been done, so I will soon
> present a proposal for a better alternative. Working on it.
> I find this matter very important.
>
> I do not agree with the for-loop removal proposal authored by Erica Sadun,
>
> Important:
> I would like to emphasize again that what I write is not intended
> personally.
>
> Also I realize that I am a bit late on this subject, but that is because I
> was not here back then.
>
> I wil go through it point by point and try to explain why IMHO I think
> this is not a good proposal.
> -
>
> Evaluating proposal SE-0007
> Remove C-style for-loops with conditions and incrementers
> • Proposal: • Author(s): Erica Sadun
>
>
>
> "The C-style for-loop appears to be a mechanical carry-over from C rather
> than a genuinely Swift-specific construct."
>
> Could you explain to me why what, in your view, is
> -  a "genuinely Swift-specific construct” ?
> - "not very Swift-like" ?
> - "Swift-typical” ?
>
> "It is rarely used  and not very Swift-like."
>
> This is definitely not true.
> The classical for loop is one of the most frequently used language
> constructs in most programming languages.
>
>
> "More Swift-typical construction is already available with for-in
> statements and stride."
>
> Except for collections, these are inconvenient, cumbersome and
> inefficient  "work arounds" as described later in my comments in this email.
>
>
> "Removing for loops would simplify the language."
> Removing screw drivers from a toolbox would indeed simplify the toolbox.
> So would removing closures, classes, protocols etc. from Swift.
> Simplification of a programming language can also have its disadvantages.
>
> " And starve the most common use-points for -- and ++, which are already
> due to be eliminated from the language."
>
> "The value of this construct is limited and I believe its removal should
> be seriously considered"
>
> There absolutely is no need to remove the for ; ; and