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

[Ted F.A. van Gaalen]

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<x1; i++)
(also with floats)
and perhaps also for a collection based variant such as:

     for v in stride(from -8.4, to: 3.2, by 0.1)

In any case, I don’t know for sure. I am not a compiler specialist
Therefore I void our argument about whether or not the compiler
can do enough magic to get it right.

Still, there are no good alternatives for the many advanced possibilities
which traditional for loop offers.
E.g.
In the Apple TV app I am currently working on I had to refactor
my for ;; loops with reversing floats with step values to “while” loops!

So, to me the best option is still to bring the for ;; back
or to make a new Swift equivalent for it as described here again.

for d from 10.0 to 5.0 by -0.1 tolerance 0.01  //tolerance is optional
{
    print(d)
}
 
-=straight from the front line: =-
Because my music maker apps RavelNotes and RavelNotesBasic are still
for the most part Objective C sources, I only have to do this in the Swift
sources of my apps. 
Now, I have to refactor (only) about 10 for ;; loops to for in.. loops
and have to convert about 10  ++   to +=  things. 
Luckily, they are all for-loops with integers, so the refactoring 
itself took less than hour, that was no problem.
However, now I have to thoroughly retest everything again, 
costing me several days or so, before I can submit a 
new release of my  apps to the app store!!
I am still lucky not to work for a company and 
having to convert a lot more source code.
I was considering converting more ObjC to Swift, put
put this on halt until Swift stabilizes.

Now, like me, many programmers have to do a 
whole lot of nasty for-loop refactoring!

Therefore, excuses moi, but currently I can’t help 
being in a state just somewhere between 
annoyed and aggravated because I am unnecessarily 
waisting lots of time  due to some puritan obsessed 
decisions,  partially from some people with high 
theoretical knowledge but very little  practical experience, 
or so it seems.  
Don’t get me wrong: 
Swift is great, e.g. i like the new protocol developments, and of course I understand 
(and support) that one needs to be very thoughtful about components of the language. 
But one should be pragmatic as well. 
 -==- 

You also wrote:

> 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 <taras.zakharko at uzh.ch> wrote:
> 
> 
>> On 31 Mar 2016, at 14:12, Ted F.A. van Gaalen <tedvgiosdev at gmail.com> 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 can be statically dispatched and inlined by the compiler. They can potentially even be unrolled (although I doubt that Swift optimiser does this kind of optimisation currently). Again, the difference between
> 
> for(int i = x0; i<x1; i++)
> 
> and
> 
> for(int i = iterator->next(); !iterator->endReached, int i = iterator->next()) 
> 
> is just one level of indirection. If the value of iterator->next() is available at the compile time and the compiler can safely assume that the iterator has a unique reference, the code can be inlined, producing the same loop as above
> 
>> 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…  
> 
> I am not at all a fan of the stride() method because they are weird to read. However, a stride() global function will do the job just fine, as shown by the example of such languages as R and Python, which are used quite prominently in the numerical domain (there the functions are called seq() and range() )
> 
>> For the simple reason that there are no collections involved: 
>> I have very clearly described and motivated it. 
> 
> Your description clearly involve numerical sequences. So they perfectly well fall into the domain of sequence-based iteration. 
> 
>> I took the liberty to read about you on the internet. Interesting.
> 
> Thank you, its very flattering :) 
> 
>> 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?  
> 
> 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. I simply see no purpose into making the language more verbose and complicated for no particular gain. 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. 
> 
> Best, 
> 
> Taras

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160405/98c6b228/attachment.html>