[fpc-pascal] for .. in loop implementation

[Vinzent Höfler]

Jürgen Hestermann wrote:

>> Mantra: First make it work, then make it fast.
> 
> In general that's true from the programmer's viewpoint. But this does 
> not apply to adding language details because there is no 'first make it 
> work'. Why obscure important implementation details if the only benefit 
> is saving some writing?

I won't judge on the "only save some writing" here, but generally it 
*does* apply to language features: If a particular language feature 
helps you writing correct code faster (by supporting you to make it work 
instead of relying on your abilities to use the debugger), then it does 
apply.

The real question is if the (or any other) proposal is "good enough" to 
do just that, or if it's really some syntactic sweetener (not even 
sugar, sugar at least contains energy). That's something to discuss.

Let me take a rather extreme point of view: After all, all those for-, 
while-, and repeat-until-loops are only there to save you from some 
typing work[0], because Pascal already has a perfectly good 
loop-construct with which you can do all that: goto. Would you agree 
here? Probably not.

>  > BTW, any performance differences in the example above highly depends
>  > on the work done in the loop body anyway, so whining about possible
>  > performance issues is quite a bit premature here. ;)
> 
> Maybe, but you started talking about performance. ;-)

Nono, you did: "Everything that obscures what's going on under the hood 
has the potential to generate performance problems."

IMO, almost every language construct of a modern language (modern as in 
"invented about 30 years ago") has the potential to just do that. Loops 
may hide costly branches, string concatenations may hide costly memory 
copy operations (not even talking about AnsiStrings here, where an 
additional overhead of memory allocation/deallocation may occur), costly 
lookups and indirect calls are hidden by virtual methods that may look 
like simple procedure calls, or the worst: operator overloading enables 
the programmer to hide practically anything inside a simple "+" (nothing 
stops you from doing "c = a + b" where "a" and "b" are pulled from an 
internet daabase and "c" is stored back there, all hidden in a simple 
addition), etc. pp.

Even in C (which is a language widely accepted as one where nothing is 
hidden from the programmer[1]) you can assign structs to each other 
which - depending on the size and layout of the structure - may result 
in rather costly memory copy operations.

So to get to the point, finally: The argument that some particular 
language construct has the potential to generate performance problems is 
NIL. IMNSHO.


Vinzent.

[0] By removing the need for labels.
[1] Nothing but bugs, hehe. :-> SCNR.