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

[Alexander Klenin]

On Sun, Jan 27, 2013 at 8:40 AM, Mark Morgan Lloyd
<markMLl.fpc-devel at telemetry.co.uk> wrote:
> If you can't define a tuple type then you can't check that it's
> assignment-compatible with e.g. an array.
I do not see a link here.

>> 2.2) Tuples construction: after some thinking, I propose to define a
>> plain comma as an operator creating a tuple.
>
> I must say that I prefer the idea of any collection being in some form of
> brackets. I'm tempted to say "any language extension being in bracket-like
> entities", even if that's paired keywords.
Nothing stops you from adding extra brackets, if you like them.
However, I think that in all cases:
a, b := b, a;
for v, k in a do
DrawLine(Tuple(r), clRed);
Nothin useful is gained by abbing extra pair of brackets.
Also, "comma is always a tuple" removes grammar ambiguity --
there is no need to look ahead after the opening bracket.

>> 2.2.1) Tuples are *flattening*, so (1, 2, (3, 4)) is a tuple of 4
>> elements, not of 3 elements, last being tuple.
> I've got a bad feeling about that. Apart from anything else I think it
> implies that (pseudocode)
>
> (TPoint, TColor) := (TColor, TPoint);
>
> would be valid.

No, you'll have to write
Tuple(APoint), AColor := AColor, Tuple(APoint);

>> Single-value tuples are
>> useless, so Tuple(1) is either a no-op or error.
>
> Except that a variant of that could be used to expand an element to a tuple.
As Sven pointed out, the main problem with that is that expression type now
suddenly depends on context, which is quite a rare feature in
programming languages,
and is probably much bugger change to Pascal than this whole tuple business.
OTOH, define Tuple(x, 5) to mean (x, x, x, x, x) is quite possible,
although less convenient:

x, y, z := Tuple(0, 3);
arr := Tuple(x, Length(arr));

--
Alexander S. Klenin