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

[Hans-Peter Diettrich]

Alexander Klenin schrieb:

>>> Also note that in my version of proposal, nested tuples are impossible.
>> I consider this an inacceptable restriction. Records can contain other records.
> Yes, but tuples are just a syntax for constructing/deconstructing
> records, not records themsleves.
> They can be converted to a specific record type by casting.
> Consider these examples:
> var
>   x, y, z: Integer;
>   pt: TPoint;
> ...
> (x, y)                      // record a, b: Integer; end;
> (x, (y))                    // record a, b: Integer; end;
> (x, (y, z))                // record a, b: Integer; end;
> (x, TPoint(y, z))       // record a: Integer; b: TPoint; end;
> (TPoint(x, y), TPoint(y, z))       // record a, b: TPoint; end;
> (TPoint(x, y), pt)       // record a, b: TPoint; end;
> (TPoint(x, y), Tuple(pt))   // record a: TPoint; b, c: Integer; end;

I don't see the correspondence between the left and right sides, sorry.
I also dont see whether the left sides are tuple constructors or
deconstructors, what's the intended effect...


>>>>> * Possible extensions
>>> This is why I think tuples as a data type are not needed.
>>> Instead, I suggest them as a powerful way to manipulate
>>> records, arrays, and parameter lists using one relatively simple concept.
>>
>> I doubt that a concept alone will help. I see the proposed extensions as an
>> attempt to introduce elements from *functional programming* languages, for
>> which OPL lacks many prerequisites.
> True, functional programming is certainly the lergest modern paradigm
> still lacking from FPC.

What's "modern"? I've learned about functional programming in 1970 - did
all the following languages miss something important?


>>> BTW, I just remembered another tuple usage example:
>>> type
>>>   T3DMatrix = array of array of array of Double;
>>>   TMatrixPos = array [1..3] of Double;
>>>
>>> procedure P(A: T3DMatrix; APos1: TMatrixPos);
>>> begin
>>>   A[Tuple(APos1)] := 1.0; // Instead of A[APos[1], APos[2], APos[3]]
>>> end;
>>
>> I'd accept a TMatrixPos as an array of Integer,
> That was just my mistake, of course i meant aray of Integer, sorry.
> 
> 
>> Why do you expect any difference between
>>    A[Tuple(APos1)] := 1.0;
>> and
>>    A[APos1] := 1.0;
>> ?
>> The compiler will have to create the same code for both notations, or use
>> the same RTL subroutine for doing the job.
> The idea is that second case will require a manually-written operator[],
> while the first one will work automatically.

NACK. How comes that the compiler should break a tuple into a list of
indices, but not an array? In detail when the tuple contains such an array?


>> One problem with error codes is their data type. Booleans are not always
>> sufficient, integers have no obvious meaning. That's why I prefer to use
>> enumerated types with descriptive names. Which types would your *standard*
>> return tuple contain?
> Note again that I did not mean tuple to be a type, so what I suggested is a
> convention, which might be adopted by some library for real-time,
> embedded or other
> low-level usage where exceptions add too much overhead:
> res, error := SomeFunction(params);
> where types of result and error will be chosen as appropriate for each function.
> The advantages over usual
> res := SomeFunction(params, error)
> being:
> 1) Easier to read, once reader knows the convention
> 2) Ignoring error is more prominent:
> res, nil := SomeFunction(params);
> 3) Since the result is actually a record, functions may still be
> chained, while ignoring errors:
> SomeFunction1(SomeFinction2(params).res);

The latter looks like breaking tuple rules, by acessing a tuple element 
by name.

This means more writing, and the typical use of error codes becomes much
more complicated IMO:
   if f(x, res) then ...
has to be rewritten as
   res, error := f(x); //or: (res,error) := f(x);?
   if error then ...


>> Of course this could be optimized, when the compiler is extended to
>> move the result tuple into distinct hidden subroutine arguments (types
>> omitted):
> Note that at machine code level, there is no difference between
> "distinct hidden subroutine arguments"
> and "single result of a record type", so compiler already does what you suggest.

That's why I wonder about yet another syntax proposal. Your proposal
*requires* that a record/tuple type *is* used for the result, where 
otherwise the subroutine could return the result in an CPU or FPU 
register, ready for immediate further use.


P.S.: A friend told me that tuple elements can be accessed by index. I'm 
not sure whether we should add such a compiler magic, though. I think 
that this feature is a workaround for access by name, which is missing 
from the mathematical/abstract tuples.

DoDi