[fpc-devel] for-in-index loop

[Sven Barth]

On 25.01.2013 19:32, Michael Van Canneyt wrote:
>
>
> On Fri, 25 Jan 2013, Sven Barth wrote:
>
>> On 25.01.2013 17:18, Alexander Klenin wrote:
>>> With this in mind, consider a user who wants to iterate over the
>>> following array:
>>>
>>> var
>>>    a: array [1..5] of Integer = (1, 2, 9, 4, 5);
>>>
>>> In my proposal, he should write:
>>> var
>>>    v, i: Integer;
>>> begin
>>>    for a in a index i do
>>>      Writeln(i, ' ', v);
>>> end.
>>>
>>> In your proposal, he should write (suppose GIter is a unit
>>> implementing the generic array iterator):
>>> uses
>>>    GIter;
>>> type
>>>    TArrayIntIterator = specialize TArrayIterator<Integer>;
>>>    i: TArrayIntIterator.TElem;
>>> begin
>>>    for i in TArrayIntIterator.Create(a) do
>>>      Writeln(i.Index + Low(a), ' ', i.Value);
>>> end.
>>
>> One could also do an alternative (though currently not with arrays,
>> but with type helper support even that would be possible...):
>
> Talk about a choice between the plague and cholera...
>

I know why I first added the example with a normal (nested) procedure.

> If I must choose between the proposed extension of for in index do
> and having anonymous functions, then I choose for for in index :)
> (and most likely ending up with both monstrosities)

Though it might be easier to "fight" against the "for-in-index" as 
anonymous functions are supported by Delphi... ;)

>
> Pascal is an explicitly declarative language. Anonymous functions go
> 100% against this. It is the readability horror I associate with
> Javascript.
>

The syntax is indeed very ugly. I personally would prefer real lambda 
expressions(!) more. To use the example from my previous mail:

=== example begin ===

map.Iterate(lambda TFPGMapLongInt.TIteratorProc(aKey, aData) as 
Writeln(aKey, ' => ', aData.ClassName));

=== example end ===

I'm in so far in favor of anonymous methods (or lamda expressions) as 
they allow you to keep the logic together (in the example the fact of 
iterating with what the iteration does). Another example which would 
apply to TThread (I'll use my lamdba syntax again):

=== example begin ===

Queue(lamda TProc as fSomeReferencedMemo.Lines.Add(fSomeText));

=== example end ===

I think this is more understandable/readable than having to add a 
"AddTextToMemo" method and a "fTextToAdd" field and then 
Synchronize/Queue that method...

> I often wonder: why do people who seem to think that Pascal misses so
> many - apparently essential - things, even bother to use it ?
>

I personally wouldn't call many of these features essential, this 
includes anonymous functions and helper types equally. You can achieve 
what they provide yourself, but if the compiler aids you with this, you 
can move a part of the responsibility for correct code to the compiler 
(which should be considered a good think from the POV of a user) and it 
can also increase the readability.

> If I thought Pascal was missing so many things, I would simply use
> something else instead of trying to turn it into something that it is not.

Languages evolve. Natural languages as well as programming languages. We 
might not agree with every change (e.g. in German there has been 
established the nasty habit of saying "that makes sense" ("das macht 
Sinn") while the correct equivalent would be "that has sense" ("das hat 
Sinn") or "that is sensful" ("das ist sinnvoll")), but we can not stop 
this evolution. Languages that don't evolve are dead, because noone 
speaks them anymore (as everyone will always add his one character to 
the language, though granted this is not as easy for programming 
languages as you need to work in the compiler/interpreter). Hadn't 
Borland decided to bring out Delphi and thus the completely different 
object model (which I personally think is in most points superior to TP 
style objects, to those have their pros, too), but instead kept e.g. 
Turbo Pascal for Windows we might not be talking together here today.

Regards,
Sven