for loop with custom step width (esp. ≠ 1)

[skalogryz]

Agree. But as me - and Molly too -  wrote: sometimes a step-like syntax comes in handy. Loads of examples in the thread here.

I didn't see a single example where it actually comes in handy! (see my earlier question about an algorithm).
Plenty of code in the thread on how to replace the functionality, but not an actual case where STEP is actually useful.

[Thaddy]

My vote was NO btw, leave as is. Provide when needed. It is actually -only- useful when you quick-translate code from another language into Object Pascal.
More like prototyping, in that sense.

[ArtLogi]

While x Do y Until x is z.  Nice and clear.

I voted 42, since I want a calculator with that model number.

[marcov]

While x Do y Until x is z.  Nice and clear.

I would like an except clause :-)

While X do y Util x is z and not A except b finally c end; 

Seriously, I would use BY

for i:=x to y by 2 do

since that is commonly used in Wirthian languages. Step is Basic, not Pascal/Wirthian.
But IMHO the frequency of the construct is too low to warrant special syntax, and it is better to use while

[Thaddy]

How about, ahum, Fortran-like syntax? Step= +/- 1 by default, but how about:

Code: Pascal  [Select][+][-]

1. for i := 0 to 99, 2 do  // this resembles Fortran's do syntax (which is different from pascal, only slightly related)
2. begin
3. //steps two
4. end;

Clean and clear

In general I have a slight problem with ignoring a step like statement and always referring to the loop constructs that are already available.
The problem is - after a good night's sleep - that those require action, a state to occur if you will, inside the body of the loop whereas a for to do loop has a finite, defined end by itself.
And that is OUTSIDE of the body of loop!!!
That is semantically totally different from the point of view of a language.
So: Yes, there is a case to be made (theory, there's logic). And no, it is not strictly necessary (in practise).

Plz don't comment if you are not proficient in language design (or OP of course!) (followed classes is sufficient) . Any other replies are welcome.
Nuance: if you feel sufficiently cocky about the subject and you understand this, of course, reply on content. <grumpy mode: heey it's almost Christmas  >

[ArtLogi]

https://cdn.meme.am/cache/instances/folder534/500x/57604534.jpg

Code: Pascal  [Select][+][-]

1. for i := 0 to 99 do inc 2 // with no mystery arguments and commas
2.   begin
3.     //steps two
4.   end;

[ASerge]

Code: Pascal  [Select][+][-]

1. for i := 0 to 99 do inc 2 // with no mystery arguments and commas
2. ...

It's not so good, can be confused with:

Code: Pascal  [Select][+][-]

1. for i := 0 to 99 do inc(l, 2);
2.  

[Thaddy]

Actually I like inc 2 as opposed to inc(z,x); as do I like "by" as suggested by Marco.
If a step loop with a defined end independent of a loop's body  were to be implemented those are strong candidates.
From parsing pov it should be before the do, I guess. See Marco's "by" suggestion.

[Josh]

My 2 cents.

I think adding functionality to the for loop statement is still not a good idea purely for compatible reason; as any code with it in would be non compatible with delphi and other version of pascal; including fpc.

If it was to be added I think maybe an additional loop variation ie

ForStep i:=a to b step c do

I know its very 'basic' but keeps for loop intact and to spec.

[Thaddy]

josh, did you consider my argument?
If you did, you realize that there is a missing structure in the language.
If you agree with that, the missing structure, there is really a point to be made to enhance the syntax.
The point is of course that Pascal does not allow finite loop syntax with steps (w/o terminate causing code inside a block).
That is a deficiency.

I really don't care if it is implemented with a comma, "by", "step", "inc" or otherwise.

[molly]

I think adding functionality to the for loop statement is still not a good idea purely for compatible reason;

As is with any extension / new feature added by FPC.

as any code with it in would be non compatible with delphi

From my personal perspective that is their problem, not mine, neither FPC's.

There are many other features to FPC/Lazarus has that Delphi hasn't. Should these functionalities be removed solely because of that ?

afaik the whole idea behind FPC is to offer Delphi compatibility for those that can't life without or wish to support both.

In any of my new projects i avoid Delphi compatibility like a plague as for me that would mean going backwards.

If you want to stay Delphi compatible then you already have to make that choice right from the start of your project and avoid FPC/lazarus specific extensions/features. I would like to emphasize on the word choice there, as it is yours to make.

If you don't like a new for loop extension (given that it would be supported, which i think it won't), then simple don't use it to stay Delphi compatible.

and other version of pascal; including fpc.

Also that is imho a non argument.

TP<>OBJFPC<>DELPHI<>ISO-Pascal

And those are the ones known to most (as well as supported by FPC). There are many other Pascal dialects out there that FPC is incompatible with. And no, it does not matter.

With every new release more features are added to FPC/lazarus, rendering the new functionality incompatible to previous versions of itself. It is just normal program development flow. At times it is even decided to renders things incompatible and break existing code, simply because that is the better choice on the long run.

I'm more in line with Thaddy's view (and i welcome his input since he's far better articulated).

As already stated: for me personally it would help with porting code from other languages, so it would indeed and most probably not be used much as correctly mentioned by marcov. As soon as a port works (currently using something similar to Thaddy's while example), then the actual rewrite starts in case a project is worth it.

Although the remark that it will not be much used to warrant implementing it, is imho a bit of a self-fulfilling prophecy, most probably because of the reasons mentioned by you: to stay compatible with other Pascal dialects/compilers. But as mentioned, that is a choice (an important one nonetheless)

[marcov]

There are many other features to FPC/Lazarus has that Delphi hasn't. Should these functionalities be removed solely because of that ?

In the (distant) past I would have said no, but several crucial changes in FPC appeared in Delphi later, but of course some of them slightly incompatible.

- exit(x)
- pointermath functionality. (always on in FPC mode)
- (default)formatsettings
- In newer versions they are experimenting with non COM interfaces.
- ptrint/ptruint

These were all part of FPC 2.0 in 2005.

However, much what remains is mostly ego driven syntax (syntax only, barely a real feature in sight), implemented to make a mark on the project, or a cramped attempt at being "different", rather than to make things possible that weren't before. Style and taste, not function

With maybe the exception of generics syntax (while deliberately different from the rest of the world, I somewhat believe that that had at least some parser benefits, but one could discuss of ease of implementation should always be the single deciding factor)

Compatibility is hard work and unsexy. Own syntax is something you can point to later. But that is a boon for the developer only, not the user.

afaik the whole idea behind FPC is to offer Delphi compatibility for those that can't life without or wish to support both.

Opinions vary. Many of the more Delphi oriented persuasion see a lot of the FPC syntax offering as a mere teenage rebellion against conforming to convention/compatibility. It is so much easier to have delusions of grandeur than do gritty work to marginally improve compatibility.

In any of my new projects i avoid Delphi compatibility like a plague as for me that would mean going backwards.

Words like "backward"/"forward" in language/dialect discussions are key signs of bias.

Note that before 2005-2007 I was a hardcore believer in FPC only syntax, but with FPC 2.0 more and more Delphi packages became available, and the practice of the own syntax turned me against it. It is needlessly divisive (the pascal community is small enough already), and the gains are token only. If at all.

If you want to stay Delphi compatible then you already have to make that choice right from the start of your project and avoid FPC/lazarus specific extensions/features. I would like to emphasize on the word choice there, as it is yours to make.

If you don't like a new for loop extension (given that it would be supported, which i think it won't), then simple don't use it to stay Delphi compatible.

Yes, just like Babel. Everybody his own dialect, and towers never get finished.

[munair]

This may indeed be an endless discussion. I found it because I'm at the point of implementing it in another compiler. Having experience in both BASIC and Pascal, I never really missed a stepping option as they usually have in BASIC dialects. There is a clear difference between the two in this respect.

For years I programmed in BASIC and found that more often than not I forgot to specify a negative step, which is mandatory for an up-down iteration, only to find myself wondering why the loop didn't work. So a syntax like

Code: Text  [Select][+][-]

1. for i = 10 to 0 step - 1

is counter-intuitive because the loop wouldn't work without the [step - 1] while for a down-up iteration the step keyword is optional.

Pascal has a better syntax IMO by differentiating between to and downto, making it immediately clear what the loop is doing.

Then comes the question, should that syntax be extended like:

Code: Pascal  [Select][+][-]

1. for i := 10 downto 0 step 2 do

IMO this syntax is too much and messy and the same result can be achieved more elegantly using a variable loop.

[marcov]

@molly
The OP explicitly talks about a for-loop and "everything regarding iteration is in the top line". Of course you can do it with a while/repeat loop. It can be done even with a recursive function. 

In Pascal, a for loop has a precalculated number of iterations.  One could argue that this C case either way (since this case essentially can be evaluated), but OTOH C doesn't require that ).

If it doesn't adhere to that, it is not a FOR loop in Pascal context, regardless whatever token the foreign language may use.

The for..in loop in FreePascal is more like the C case, as the number of iterations is not predefined, in similar discussions people have tried to emulate such behaviour with a record and for..in. Search the forum

[munair]

In Pascal, a for loop has a precalculated number of iterations. One could argue that this C case either way (since this case essentially can be evaluated), but OTOH C doesn't require that ).

I suppose by "predefined" you mean that the start / end values are calculated before the start of the loop. This is the easiest and also more optimal approach. More flexibility is always possible using variable loops. No need to make things more complicated IMO. For-loops are essentially for iterating through data elements one-by-one.

I was actually thinking about implementing a stepping option in SharpBASIC but this thread among others convinced me that with variable loops available, there's no need to start messing with for-loops.