[fpc-devel] RFC: Support for new type "tuple" v0.1

[Michael Van Canneyt]

On Mon, 28 Jan 2013, Alexander Klenin wrote:

> On Mon, Jan 28, 2013 at 2:59 AM, Michael Van Canneyt
> <michael at freepascal.org> wrote:
>>
>>
>> On Mon, 28 Jan 2013, Alexander Klenin wrote:
>>> I have a compromise suggestion:
>>> Implement for-index extension with the syntax:
>>> for (k, v) in a do
>>> this syntax is forward-compatible with both tuples proposals,
>>> is simple to do (basically, already done -- only a small change in
>>> parsing is required)
>>
>> what concerns syntax, I have no problem with this.
>>
>> What bothers me immensely is the same what bothered me in the totally
>> braindead
>> Delphi implementation of the "for in" loop : the bunch of requirements you
>> put on the iterator implementation: an interface with special status. You
>> can't get more stupid and ugly than that.
> Out of curiosity -- how would you implement it?

Define an iterator type/operator.

- No interface
- No 'specially named function' in the class. The iterator should be separate from the class.
Now they promoted 1 function with a special name to a special status: 'GetEnumerator'

(I know this is how Python and so did it, but I'm not particularly fond of that either).

> (Except "the Oberon way" -- by telling the programmer that he is
> better off without this feature :-))

I am still not convinced that language support for iterators are needed.

You may be bothered by the various loop methods in the rtl/fcl.
But I am not in the least bothered by it.

> I have no particular like or dislike for the Delphi's enumerable implementation,
> but it is quite similar to for-in iterators in most other compiled languages.

Well, I do not like to give special status to certain functions or interfaces.
All identifiers should be equal for the law :-)

I was horribly disappointed when they introduced that.

>> Your initial proposal makes it even worse by adding more conditions to the
>> interface, it would not even be an interface any more.
> I am not sure what are you talking about. Interface is a list of methods.
> My for-in proposal would add a new interface (with a single method)
> which, if supported by enumerator, would allow user to write for-in-index loops.

I know. I just do not like the approach. 
Probably because I don't particularly like interfaces themselves.

>> That is why I think you need a proper "tuple" value to solve this.
>> it gives a more fundamental solution: the loop variable type equals the type
>> returned by the iterator/enumerator. No messing with index (bad syntax) and
>> even worse: special 'interfaces' and whatnot.
> I agree that "index" keyword was perhaps not optimal choice.

Quick, we should call the newspaper, we agree on something ;-)

> New interface is needed anyway to preserve backwards compatibility
> (and efficiency for the case when the key is not needed).
> "Do not slow down existing code".

Yes.

>> Pascal is a strongly typed language. So, if we absolutely must solve this:
>> introduce a proper type. A tuple fits the job.
> So does the record -- tuple is needed here only to deconstruct that
> record in separate variables.

True.

Which begs the question why you didn't use a record to begin with.

I still do not see why the enumerator could not simply return a record
record
   key : tkey;
   value : tactualtype
end;

for r in myclass do
   begin
   Writeln(r.key);
   With r.value do
   end.

to recapitulate:

The construction with interface/index is really very ugly in my opinion, 
and I would very much regret it if it became part of Object Pascal.

I can understand the need to have simpler variables. 
So a tuple and/or a record deconstructor comes in naturally.

I think a tuple as a type construct may have value in itself.
and as such would prefer to see it as a 'first class citizen' of Object Pascal,
just as it is in e.g. Python, and to a lesser degree, other languages.
The exact details are for me less important.

A small word:

Like most people here I think Pascal is an elegant language, easy to read 
and whatnot. It was meant/designed as such, and Wirth did a good job.

I am very passionate about that, I'm sure you noticed. I may use 
exuberant language, and probably bad humor, in my efforts to defend it.

Despite that, please do not make the mistake of thinking that I would stop 
features just because I do not like them. That said, I will zealously defend 
possible alternatives that I think add to the elegance and readability of Pascal.
(as witnessed by the discussions this weekend...)

Borland did a world of good for (Object) Pascal, up to Delphi 7.
After that, it went seriously downhill in my opinion; 
Adding randomly features without clear direction or regard for the
intent and philosophy of the Pascal language - or so it seems to me.
Like a ship at the mercy of the waves...

I would be very sorry to see that happening to Free Pascal.

Michael.