[fpc-devel] for-in-index loop

[Daniël Mantione]

Op Sat, 26 Jan 2013, schreef Alexander Klenin:

> On Sat, Jan 26, 2013 at 5:12 AM, Daniël Mantione
> <daniel.mantione at freepascal.org> wrote:
>>> Consider these arguments:
>>> 1) Even for simple arrays, depending on array element type,
>>>  and optimizer implementation, for-in can be more efficient since it
>>> can avoid multiplication for element access.
>> True, but it shouldn't. Loop induction is such a well documented
>> optimization that implementation of that optimization (could be a nice job
>> for a student) is by far preferable over mutilating the language.
> I argee. Still, for the general container such an optimization is
> hard-to-impossible to implement.

?? For the general container figher['ninja'] would not be implemented by 
multiplication.

>>> 2) If "a" is a function of another complex expression returning an
>>> array, then "for-in" may be much more efficient and compact
>> Again true, but again easy to avoid: temp variable, with statement, common
>> subexpression elimination. Again these are all preferable over mutilating
>> the language.
> "with" statement of of course not help (try it).

If you cannot use with directly, wrap the array inside a record.

> CSE might help, but is tricky across function boundaries -- function
> must be first proven to be pure,
> which is non-trivial in Pascal.
> temp variable is, of course, always a solution -- but so is using while loop
> or even labels and goto. I am tying to make Pascal higher-level language,
> as opposed to, e.g. C, which is determined to stay at low level.

I understand your goal, which is commendable. The challenge is to do it in 
a way that doesn't turn Pascal in something it is not.

> Please try to define a mapping between String and Integer :)

const integer2fighter:array[0..3] of string=('knight','ninja','samurai','swordman');

function fighter2integer(const s:string):integer;

begin
   {implement binary search}
end;


>>> 4) If there is no uniform method for iterating over containers, then
>>> each container will define its own method,
>>>  with the end result that the language will be *more* complex for the
>>> user, who will have to remember all these methods.
>>
>> This I consider a valid argument, and it affects the fundament of what a for
>> loop is. A for loop iterates over the keys only, while the values are
>> retrieved by [] syntax. This is perfectly possible even for non-numeric keys
>> as we have properties that allow you to do a['elephant'].
> First, for-in loop is not a for-loop. It is unfortunate that due to the need to
> avoid new reserved words, "for" war chosen instead of more logical
> "foreach" or even "for each".
> But nevertheless, they should not be confused.
> Similarly, I have chosen "index" instead of more logical "key",
> which tricked some developers into thinking that I am talking about
> indeger indexes only.
> Second, accessing the associative array element via key has non-trivial cost,
> which is avoided by using foreach-type loops.
>
>> The for-in syntax violates this fundamental property by returning values,
>> which means there is a lack of a key. The fundamentalistic view then says we
>> should not have for-in in Pascal, because it changes the fundamental
>> property of a for-loop.
> "fundamentalistic" is a right word here.

Yes... because it's wrong to always stick to principles if practical 
problems are to be solved. But it's also wrong to add too much pragmatic 
exceptions: With software it becomes hard to maintain, with programmings 
languages it becomes unelegant and hard to learn.

Pascal was such a breakthough in the 1970's because of its elegance. That 
should always be kept in mind when extending the language. (And has been 
forgotten too often unfortunately.)

>> For pragmantic reasons the for-in syntax got supported. However, when using
>> it you discover the lack of keys. So you want to repair something that's
>> already broken by design.
> I do not see why it is broken -- only because it is contrary to the
> fundamentalist view?

Bottom line: yes. Language design is a lot about esthetics. Having many 
syntaxes for things as simple as a for loop is bad tasted. The amount of 
syntax is getting out of hand.

Daniël