4 ms·
For a language that specifically says it has manual memory management, it makes sense that there are no implicit iterators. I guess what you want can be done at
by mariusor 6y ago
For a language that specifically says it has manual memory management, it makes sense that there are no implicit iterators. I guess what you want can be done at compile time and work without them, but probably it's a lot more work than what manual indexing requires.
- pjmlp 6y agofor i := 0 to len(greetings) do and if bigger increments are desired, e.g. for i := 0 to len(greetings) step 2 do
- mariusor 6y agoThat's a lot of extra keywords.
- Jtsummers 6y agoI suspect the bigger point being made by GP is that languages with manual memory management and iterators are not an incompatible concept. Given pjmlp is the commenter I suspect the language he's using is Pascal or another Wirthian language. See also Ada for another example of a language with manual memory management and iterator constructs. It may introduce some extra syntax/keywords though, which could be against what seems to be a minimalist approach (from the sample).
- pjmlp 6y agoCode is read more than written, readability matters.
- tom_mellior 6y agoIf readability matters, there shouldn't be an extra counter variable for the reader to keep in mind. for greeting in greetings do is more readable if nothing interesting is done with the counter itself.
- Jtsummers 6y agoAda does this. Offering both styles: for x of Some_Array loop for i in Some_Array’Range loop Allowing you to do the appropriate thing for your situation.
- pjmlp 6y agoIndeed, I just wrote the version where the counter matters, because it was used as such on the original examples. As a matter of fact, Object Pascal/Delphi uses the for in syntax when it doesn't matter.
- hctaw 6y agoNot really, iteration requires the existence of interfaces, requiring two methods (or one, if optionals are supported). Iterator semantics are orthogonal to memory management. The transformation into a while loop is a handful of lines of code (unless your implementation language sucks). It's not difficult for simple iterators (but can get dense for more generic constructs like generators).
- tom_mellior 6y ago> I guess what you want can be done at compile time Yes. > but probably it's a lot more work No, at least not if you want to limit yourself to arrays, this is a trivial thing for a compiler frontend to handle. For example, the parser could already translate the "iterator for" loop syntax into exactly the same representation as it would produce for the "counter for" loop syntax. The javac compiler for java does this: It transforms loops over arrays using iterator syntax into "normal" counter loops. Loops using iterator syntax over non-arrays are compiled to use iterator objects.
- steveklabnik 6y agoAs an example of this: https://doc.rust-lang.org/stable/std/iter/index.html#for-loops-and-intoiterator https://doc.rust-lang.org/stable/std/iter/index.html#for-loo...
- tom_mellior 6y agoI don't see iterator syntax being desugared to a counted loop there. I don't doubt that the Rust compiler eventually produces a counted loop when iterating over a vector, but this link doesn't demonstrate that.
- steveklabnik 6y agoIt’s not a counted loop, it’s true. for loops are sugar for iterators and an infinite loop + break. My point is that it is not a particularly complex transformation, as you said. I thought the complexity (or lack thereof) was the high order bit. Sorry I should have been more clear!