On Mon, Mar 21, 2016 at 9:05 AM, ted van gaalen via swift-evolution < [email protected]> 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 floating point > numbers perhaps be enhanced like so: > > for v from 0.0 to 10.0 by 0.1 tolerance 0.01 // tolerance > optional clause > > so that it reaches the end value 10.0 in this case > > (I am not in favor to automatically set tolerance based upon magnitude) > > To summarize: > > 1. the existing for ... in ... which is nearly perfect for collections > can remain as is. No conflicts here. There is no need to drop one for the > other, they are completely independent. > > 2. The new for ... from ... to ... by ... is simple,straightforward and > easy to implement. > > You've mentioned this: > > for (i,j,k) in matrix.indices {...} > > but here we are working with collection (descendants), are we? > > I'd kindly recommend us all to travel much to other programming worlds, > because there are so many (often forgotten) very interesting aspects and > ideas that can be very useful to implement in new languages. > > Kind Regards > TedvG > > On 21 Mar 2016, at 14:30, Taras Zakharko <[email protected]> wrote: > > 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 < > [email protected]> wrote: > > > On Mar 19, 2016, at 12:46 AM, Dmitri Gribenko via swift-evolution < > [email protected]> 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 [email protected] Runtime Wrangler > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
