On Mon, Jan 28, 2013 at 7:25 PM, Hans-Peter Diettrich
drdiettri...@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))
On Sun, Jan 27, 2013 at 12:35 PM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
(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
On Sun, 27 Jan 2013, Alexander Klenin wrote:
On Sun, Jan 27, 2013 at 4:43 AM, Sven Barth pascaldra...@googlemail.com wrote:
Based on the results of the for-in-index thread I've decided to come up
with a draft for the Tuple type which is thought by many people to be a
better alternative to
On 27.01.2013 02:35, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
* Description
What are tuples? Tuples are an accumulation of values of different or
same type where the order matters. Sounds familiar? They are in this
regard similar to records, but it's only the order of an element that
On Sun, Jan 27, 2013 at 10:10 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
2.1) Tuples are always temporary and anonymous. You can not store a
tuple, define tuple type, of variable of tuple type.
So tuples are 100% static, compile-time feature -- no change to
RTTI, variants etc.
No.
On Sun, 27 Jan 2013, Alexander Klenin wrote:
On Sun, Jan 27, 2013 at 10:10 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
2.1) Tuples are always temporary and anonymous. You can not store a
tuple, define tuple type, of variable of tuple type.
So tuples are 100% static, compile-time
On Sun, 27 Jan 2013, Paul Ishenin wrote:
27.01.13, 1:43, Sven Barth wrote:
Based on the results of the for-in-index thread I've decided to come
up with a draft for the Tuple type which is thought by many people to be
a better alternative to for-in-index.
I think it is big overkill to
On 26 Jan 2013, at 21:45, Alexander Klenin wrote:
2.2.2) Any record or array type may be converted to a tuple of its
elements using either assignment or Tuple intrinsic.
For example: Tuple(ARectangle) is a tuple of 4 elements;
x, y := APoint; // same as x := APoint.x; y := APoint.y;
[snip]
On Mon, Jan 28, 2013 at 1:26 AM, Paul Ishenin paul.ishe...@gmail.com wrote:
27.01.13, 1:43, Sven Barth wrote:
Based on the results of the for-in-index thread I've decided to come
up with a draft for the Tuple type which is thought by many people to be
a better alternative to for-in-index.
I
On 27/01/2013 14:42, Alexander Klenin wrote:
On Mon, Jan 28, 2013 at 1:26 AM, Paul Ishenin paul.ishe...@gmail.com wrote:
27.01.13, 1:43, Sven Barth wrote:
Based on the results of the for-in-index thread I've decided to come
up with a draft for the Tuple type which is thought by many people to
On Mon, Jan 28, 2013 at 1:38 AM, Jonas Maebe jonas.ma...@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
On Mon, Jan 28, 2013 at 2:01 AM, Martin laza...@mfriebe.de wrote:
Of course. But note that in this thread, many more uses of tuples
(which I do NOT want to make a type -- see my previous mail for
lengthy explanation why).
Some of the uses are: record and array constructors, adaptation of
On Mon, 28 Jan 2013, Alexander Klenin wrote:
On Mon, Jan 28, 2013 at 1:26 AM, Paul Ishenin paul.ishe...@gmail.com wrote:
27.01.13, 1:43, Sven Barth wrote:
Based on the results of the for-in-index thread I've decided to come
up with a draft for the Tuple type which is thought by many people
On Mon, Jan 28, 2013 at 2:59 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
On Mon, 28 Jan 2013, Alexander Klenin wrote:
I have a compromise suggestion:
Implement for-index extension with the syntax:
for (k, v) in a do
this syntax is forward-compatible with both tuples proposals,
is
On Mon, 28 Jan 2013, Alexander Klenin wrote:
On Mon, Jan 28, 2013 at 2:59 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
On Mon, 28 Jan 2013, Alexander Klenin wrote:
I have a compromise suggestion:
Implement for-index extension with the syntax:
for (k, v) in a do
this syntax is
Preface: In the following I assume that tuples can be implemented by
records. The proposed syntax extensions can be applied to records as
well, they are not restricted to a new type.
Alexander Klenin schrieb:
On Sun, Jan 27, 2013 at 12:35 PM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
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
On Mon, Jan 28, 2013 at 4:19 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
Define an iterator type/operator.
- No interface
- No 'specially named function' in the class. The iterator should be
separate from the class.
Now they promoted 1 function with a special name to a special
On Mon, 28 Jan 2013, Alexander Klenin wrote:
On Mon, Jan 28, 2013 at 4:19 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
Define an iterator type/operator.
- No interface
- No 'specially named function' in the class. The iterator should be
separate from the class.
Now they promoted 1
On Mon, Jan 28, 2013 at 4:46 AM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
Preface: In the following I assume that tuples can be implemented by
records. The proposed syntax extensions can be applied to records as well,
they are not restricted to a new type.
Ok, with a few caveats listed
On 27.01.2013 20:16, Alexander Klenin wrote:
Borland did a world of good for (Object) Pascal, up to Delphi 7.
After that, it went seriously downhill in my opinion; Adding randomly
features without clear direction or regard for the
intent and philosophy of the Pascal language - or so it seems to
Hello together!
Based on the results of the for-in-index thread I've decided to come
up with a draft for the Tuple type which is thought by many people to be
a better alternative to for-in-index.
Please note the following points:
* This is not the final specification for Tuples and thus open
In our previous episode, Sven Barth said:
up with a draft for the Tuple type which is thought by many people to be
a better alternative to for-in-index.
Please note the following points:
* This is not the final specification for Tuples and thus open to
discussion (there are still some
On 26.01.2013 18:52, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
up with a draft for the Tuple type which is thought by many people to be
a better alternative to for-in-index.
Please note the following points:
* This is not the final specification for Tuples and thus
In our previous episode, Sven Barth said:
In a quick read, I cannot see any limitations to the type used for
a tuple-element except that it behaves like file of...
So that would mean a record type (or other non variant compatible type)
would qualify?
Whether there should be
On 26.01.2013 19:20, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
In a quick read, I cannot see any limitations to the type used for
a tuple-element except that it behaves like file of...
So that would mean a record type (or other non variant compatible type)
would
On Sat, 26 Jan 2013, Sven Barth wrote:
Hello together!
Based on the results of the for-in-index thread I've decided to come up
with a draft for the Tuple type which is thought by many people to be a
better alternative to for-in-index.
Please note the following points:
* This is not the
Sven Barth wrote:
Hello together!
Based on the results of the for-in-index thread I've decided to come
up with a draft for the Tuple type which is thought by many people to be
a better alternative to for-in-index.
Nice, but I've got reservations about making tuples compatible with
dynamic
On 26.01.2013 20:13, Mark Morgan Lloyd wrote:
Sven Barth wrote:
Hello together!
Based on the results of the for-in-index thread I've decided to come
up with a draft for the Tuple type which is thought by many people to
be a better alternative to for-in-index.
Nice, but I've got reservations
On 26.01.2013 20:14, Michael Van Canneyt wrote:
On Sat, 26 Jan 2013, Sven Barth wrote:
Hello together!
Based on the results of the for-in-index thread I've decided to come
up with a draft for the Tuple type which is thought by many people to
be a better alternative to for-in-index.
Please
On 26.01.2013 20:36, Sven Barth wrote:
After a first read, looks OK. You seem to have thought of everything
that needs to be described, except maybe extraction of a single element:
b : tuple of (integer, integer);
a : integer;
begin
b:=(1,2);
a:=b[0]; // a = 1 after this.
end;
In this
Sven Barth wrote:
I'd vote for
having implicit compatibility between a single element and a tuple i.e.
something like
(x, y, z) := Tuple(0);
provided that x, y and z are all the same type. Granted that the same
effect can be had by overlaying the assignment operator but this would
save
Michael Van Canneyt wrote:
On Sat, 26 Jan 2013, Sven Barth wrote:
Hello together!
Based on the results of the for-in-index thread I've decided to come
up with a draft for the Tuple type which is thought by many people to
be a better alternative to for-in-index.
Please note the following
Alexander Klenin wrote:
2) The most important differentiating features of my proposal are:
2.1) Tuples are always temporary and anonymous. You can not store a
tuple, define tuple type, of variable of tuple type.
So tuples are 100% static, compile-time feature -- no change to
RTTI, variants
On Sun, Jan 27, 2013 at 8:40 AM, Mark Morgan Lloyd
markmll.fpc-de...@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
On Sun, Jan 27, 2013 at 12:11 PM, Alexander Klenin kle...@gmail.com wrote:
Nothin useful is gained by abbing extra pair of brackets.
Sorry, I mean Nothing useful is gained by adding ...
--
Alexander S. Klenin
___
fpc-devel maillist -
Sven Barth schrieb:
* Description
What are tuples? Tuples are an accumulation of values of different or
same type where the order matters. Sounds familiar? They are in this
regard similar to records, but it's only the order of an element that
matters, not its name. So what does make them
37 matches
Mail list logo
