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

[Alexander Klenin]

On Mon, Jan 28, 2013 at 1:38 AM, Jonas Maebe <jonas.maebe at elis.ugent.be> wrote:
> you no longer have a tuple type, but rather a deconstruct_into_component_types()
> type conversion operator along with anonymous records.
Yes, this is quite close to what I wanted to propose.
I am glad someone has understood me :)
Please see arguments for this (as opposed to just a tuple type) in my
previous emails.

>The fact that the
> tuple() operator is required when deconstructing a record when calling a
> function (as in 2.3.2) while it is not when assigning a record to multiple
> values (as in 2.2.2) shows that such automatic conversions are not a good idea.
Yes, automatic conversions from records is indeed a weak point in my proposal.
It may be dropped, but at a cost of bulkier syntax:
handle, error := Tuple(OpenFile('name'));
vs
handle, error := OpenFile('name');
I am not sure whether to prefer better consistency of better readability.

Perhaps Tuple could be made a keyword instead of intrinsic, and thus
allowed to omit brackets:

handle, error := tuple OpenFile('name');
rectangle := tuple point1, tuple point2;

Alternatively, some kind of "tuple operator" may be introduced
(yes, I know, everyone is against punctuation -- consider it just a
brainstorming attempt):
handle, error := @@OpenFile('name'); // double-@ is currently useless
handle, error := ,OpenFile('name'); // crazy :)
handle, error := ~OpenFile('name'); // random unused character

> Implicitly applying it in one case and not in another is not good, and
> I'm definitely against automatically converting records into its component
> elements for passing as parameters.
Of course, since it would make it impossible to pass records as parameters :)
Tuple keyword/intrinsic is definitely unavoidable in this case.

> However, new magic
> operators that have their own rules are what really complicates a language,
> both in the compiler implementation and for people that have to use it.
Note that my proposal actually reduces the number of magic operators,
since it unifies the meaning of comma-in-parameter-list, comma-in-open-array
and comma-in-array-index to be the same comma-in-tuple.

--
Alexander S. Klenin