[swift-evolution] Striding Through Lands of Iteration

[Ted F.A. van Gaalen]

Goedemorgen David, Chris & Other respected,

      for v from v1 to v2 by v3 { }

Yes, i do see this for variant as an *additional* alternative to ranges/strides.

Regarding performance, I was under the false impression that for a stride
a complete collection was generated, but luckily this is not the case, as for each
next() a new value is calculated, not a collection element is returned

In the mean time I’ve made a new Strider variant, as described in detail
with source code in another post I’ve submitted yesterday:

for v in Strider( from: v1, to: v2, by: v3, tolerance: vtol) { Aragorn(v) }

which is also implemented (as the other stride(s) as a Double extension function.
Also able to move backwards. 

In essence, I can live with using a strider construct, because it can do everything
the classical ‘for ; ;’  loop does.  
(although the classical for-loop is way much more efficient)  

And also working with pseudo-collections as Strides are has advantages as well

(still: 
Laying under my car and trying with one hand to find
my for-screwdriver. "Sh..! Hey! Who took my really handy wrench 
out of my shiny new Swift toolbox !?! Because he/she thought
wrongly I didn’t need it anymore? And also without offering a better alternative?” )
 
 
I still think its an important Swift improvement to also have:

      for v from v1 to v2 by v3 { }

and perhaps add for real numbers, this tolerance parameter like so:

      for v from v1 to v2 by v3 tolerance vtol { }’


Not only because it is easier to think and write,
especially for those new to Swift,

@Chris:   !
but also because the Swift compiler can really boil this
down to a very efficient loop structure wit nearly no calls involved.
instead of having to get values from a generator all the time.

I’d estimate this would at least save about 10 calls or so,
but I am not sure of that, as I have no experience
with working on compilers, parsers and the like.

I assume that our compiler is not intelligent enough to
optimize this strider logic away, because it simply cannot know
in advance what values to expect from the strider sequence.

I do also still think the compiler should treat tolerance requests
for the same reason of a significant performance improvement.
(As in a previous thread I’ll pick up again) 

About reserved words:  (will also post this separate) 
In short:
                 -=  there should be none =-
A compiler should have enough intelligence to determine
from the statement’s context if a word is used as a keyword
or not.   Like e.g. in PL/1 as I posted here before. 
  ----
Lunch break  Going to get some coffee to get over
what I saw on BBC/CNN TV… 
Some things are really hard to believe.
So, to my dear American colleagues and friends:
for _ in 1..100; { print(“Please! “} 
don’t vote for someone like that.
It is already bad enough that he came that far.
https://www.youtube.com/watch?v=FK3TIYG9mqM
  ----

kind regards / met vriendelijke groeten
TedvG


> On 26.02.2016, at 21:52, David Waite <david at alkaline-solutions.com> wrote:
> 
> 
>> On Feb 26, 2016, at 9:07 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>>> Does .stride(), which in the end uses a descendant of SequenceType, just calculate a new value each time   for..in..   uses .next() on this collection? 
> 
> this.
> 
>>    for  x from xmin to xmax by xstep  { }
>> 
>>    for x from xmax to xmin by -xstep  { } 
>> 
>>    for apple from 1 to applesInTruck  { }
>> 
>> No need for collections in these cases,
> 
> As the thread for removal of C-style for showed in benchmarks, using a range or stride does not have a performance impact under optimization. Such new syntax would need to stand on its own as a second alternative to using ranges/strides. 
> 
> Considering that it would require reserving three new keywords (‘from’, ‘to’, and ‘by’) this will be a hard argument to make.
> 
> -DW
> 

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