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

[Hans-Peter Diettrich]

Sven Barth schrieb:

>> The lack of element names results in bloated code and runtime overhead.
>> See below.
>>
> 
> I don't see why it should result in bloated code and runtime overhead.

---> See below ;-)


>>>   (a, b) := (b, a); // the compiler needs to ensure the correct usage
>>> of temps here!
>>
>> What will happen here?
>>
>> At compile time a tuple type (integer; integer) has to be defined, and
>> an instance must be allocated for it. Initialization and finalization
>> information/code must be added if required.
>>
>> At runtime the arguments are copied into that tuple instance, then
>> copied into the target variables. All "copies" may be subject to type
>> conversions and reference counting.
> 
> And here you are wrong. We have an assignment node with a tuple node on 
> the left and a tuple node on the right. So the compiler can insert 
> direct assignments between the corresponding elements on the left and 
> right maybe with the need to insert a few temp vars to resolve cases 
> like the above.

Are you sure that the compiler will detect all (possible) side effects, 
so that an optimization is always *safe*?

Finally somebody (you?) has to implement all the new features, and stand 
for its correctness.


>>>   a := 42;
>>>   (a, e) := (a * 2, a); // (a, e) should be (84, 42), not (84, 84)
>>
>> Such code tends to become cryptic with larger tuples.
>> High level (source code) debugging will be impossible :-(
>>
>>
> 
> You can also write cryptic code without tuples. Also why should 
> debugging become impossible? It's "just" a matter of adding the correct 
> debug information.

With explicit assignments you can check every single statement, 
eventually step into embedded functions. A tuple assignment is a single 
statement, no chance to find out what happens in detail.

DoDi