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

[Alexander Klenin]

On Mon, Jan 28, 2013 at 7:25 PM, Hans-Peter Diettrich
<DrDiettrich1 at aol.com> wrote:
>> 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...

Right side contains examples of records which would be compatible with
the tuples on the left -- for both construction and deconstruction.

>> True, functional programming is certainly the largest 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?
Current consensus in the field of programming languages design is
that they did -- which is why FP features are added to just eny
language you look at,
from C++ to PHP :)

>>> 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?
Well, that was the idea, auto- breaking a tuple but not an array,
so by converting array to tuple programmer can control it.

>> 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.
The record becomes a tuple only by either explicit conversion,
or deconstructing assignment.

> 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 ...
That depends on the type or err



> 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.
There is no reason why a record can not be returned in a register.
Actually, there is perhaps even greater chance for that compared to
out parameter,
which is usually implemented as pointer.

--
Alexander S. Klenin