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 spe
On Sun, Jan 27, 2013 at 12:11 PM, Alexander Klenin 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 - fpc-devel@lists.freepascal.org
On Sun, Jan 27, 2013 at 8:40 AM, Mark Morgan Lloyd
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
>> plain comma as an operator c
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 et
On Sun, Jan 27, 2013 at 4:43 AM, 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".
>
> Please note the following points:
> * This is not the
Sven Barth wrote:
b : tuple of (integer, integer);
a : integer;
begin
b:=(1,2);
a:=b[0]; // a = 1 after this.
end;
Iff a tuple contains elements of the same type and if tuples with this
restriction are compatible with arrays, wouldn't this behaviour be
implicit?
The [] operator would t
On 26.01.2013 21:09, Mark Morgan Lloyd wrote:
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
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 followin
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 havi
On Sat, 26 Jan 2013, Sven Barth wrote:
grouping of values.
That's why I proposed them as extensions. I'm myself not very sure in
allowing them or not, but I added them for Alexander's sake ;)
I would also not allow operators other than := <> and =, because in
expressions,
when encounteri
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 se
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".
Plea
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 reservatio
Michael Van Canneyt 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 sense, it seem
On 26.01.2013 20:12, Alexander Klenin wrote:
On Sun, Jan 27, 2013 at 3:10 AM, Sven Barth wrote:
On 26.01.2013 16:34, Alexander Klenin wrote:
Ok, then let's take just one step back:
SomeProc(lambda TProc1 as Writeln(aArg));
This way, but problems are solved -- procedure type is specified
indep
On Sun, Jan 27, 2013 at 3:51 AM, Marco van de Voort wrote:
> In our previous episode, Alexander Klenin said:
>> >
>> > Please take a look at this:
>> > http://blog.barrkel.com/2010/01/using-anonymous-methods-in-method.html
>>
>> While this article confirms my understainding of them Delphi implemen
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
dynam
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 th
On Sun, Jan 27, 2013 at 3:10 AM, Sven Barth wrote:
> On 26.01.2013 16:34, Alexander Klenin wrote:
>> Ok, then let's take just one step back:
>> SomeProc(lambda TProc1 as Writeln(aArg));
>>
>> This way, but problems are solved -- procedure type is specified
>> independently from the parameter type,
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 qual
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
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 o
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 s
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 o
In our previous episode, Alexander Klenin said:
> >
> > Please take a look at this:
> > http://blog.barrkel.com/2010/01/using-anonymous-methods-in-method.html
>
> While this article confirms my understainding of them Delphi implementation,
> it does not offer a solution.
> The solution must come a
On 26.01.2013 16:34, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 8:31 PM, Sven Barth wrote:
On 25.01.2013 23:57, Alexander Klenin wrote:
You have also proposed lambda-expressions:
map.Iterate(lambda TFPGMapLongInt.TIteratorProc(aKey, aData) as
Writeln(aKey, ' => ', aData.ClassName));
On Sun, Jan 27, 2013 at 1:05 AM, Mark Morgan Lloyd
wrote:
> Sven Barth wrote:
> Some way of extending a single value to fill a tuple where all the elements
> are of the same type would be useful, note that I'm not suggesting any other
> relaxation of type checking.
>
> (x, y, z) := (0, 0, 0);
On Sun, Jan 27, 2013 at 1:59 AM, kyan wrote:
>> I assume this is because anonymous functions are not plain methods. Thus
>> they are not compatible with TMethod (the type behind "procedure/function of
>> object"). They are instead based on a different (internal) type.
>
> Please take a look at thi
On Sat, Jan 26, 2013 at 8:31 PM, Sven Barth wrote:
> On 25.01.2013 23:57, Alexander Klenin wrote:
>> You have also proposed lambda-expressions:
>>>
>>> map.Iterate(lambda TFPGMapLongInt.TIteratorProc(aKey, aData) as
>>> Writeln(aKey, ' => ', aData.ClassName));
>>
>>
>> I think that they are not op
let's share a beer at Delirium on friday evening with FPC developers
heading at FOSDEM,
in order to introduce to each other, projects we are working on, fields of
interest, opportunities to share common future developments,
are you on for a beer ?
Jyv.
Alexander Klenin schrieb:
I think you meant "array of const" instead of "open array", since open array is
just a method to pass arbitrary-sized array (of a single element type,
of course).
Yes, indeed. I missed that you already mentioned "array of const" as a
possible syntax/implementation.
On Sat, Jan 26, 2013 at 4:57 PM, Sven Barth wrote:
> On 26.01.2013 15:52, Alexander Klenin wrote:
>>
>> On Sun, Jan 27, 2013 at 12:26 AM, Paul Ishenin
>> wrote:
>>>
>>> 26.01.13, 6:57, Alexander Klenin пишет:
>>>
>>> Why to invent a new solution if Delphi already have one:
>>>
>>> http://docs.emb
On 26.01.2013 15:52, Alexander Klenin wrote:
On Sun, Jan 27, 2013 at 12:26 AM, Paul Ishenin wrote:
26.01.13, 6:57, Alexander Klenin пишет:
Why to invent a new solution if Delphi already have one:
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/ano
On Sun, Jan 27, 2013 at 12:26 AM, Paul Ishenin wrote:
> 26.01.13, 6:57, Alexander Klenin пишет:
>
> Why to invent a new solution if Delphi already have one:
> http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/anonymousmethods_xml.html
>
Of course, the
Sven Barth wrote:
As Michael said Pascal is a declarative language (though this has been
forgotten some times) so I'd allow the declaration of tuple types using
something like "tuple of (type1, type2, etc.)"
etc. Yes, I like it. This also sorts out the lack of multiple assignment
that somebo
26.01.13, 6:57, Alexander Klenin пишет:
Why to invent a new solution if Delphi already have one:
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/anonymousmethods_xml.html
Best regards,
Paul Ishenin
___
f
In our previous episode, Michael Van Canneyt said:
> > Is the drop still present/essential? Perhaps optimizer is now good
> > enough to drop those ifdefs?
>
> No.
>
> You never can replace a direct pointer assignment a:=B with a call to Move()
> and expect the same speed.
Unless move is an intri
On Sat, 26 Jan 2013, Sven Barth wrote:
On 26.01.2013 12:34, Michael Van Canneyt wrote:
I think now when operators for simple types are present in the
language it is too late to care about explicitly declarative language.
It is simple not explicit anymore.
And index (or better to call it key)
On Sat, 26 Jan 2013, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 10:34 PM, Michael Van Canneyt
wrote:
But if I must choose between
for a,b in c do
(with C a tuple enumerator/iterator) or
for a in c index b do
Then the former is ten times (well, a lot) better.
So if someone were to i
On 26.01.2013 12:34, Michael Van Canneyt wrote:
I think now when operators for simple types are present in the
language it is too late to care about explicitly declarative language.
It is simple not explicit anymore.
And index (or better to call it key) extension for for-in loop will
not make it
Rereading your mail now with what I wrote about tuples in mind:
On 25.01.2013 22:44, Alexander Klenin wrote:
2) Indeed, introducing tuples to Pascal might be an alternative
solution. Below is a proposal:
2.1) Tuple definition. Tuple is an anonymous list of values, possibly
of different types. It
On Sat, 26 Jan 2013, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 10:50 PM, Sven Barth
wrote:
Generics was implemented without my knowledge. I only found out when
suddenly
the classes unit had been changed to use them. After a horrible
discussion, this was reversed, because of the drop in
On Sat, Jan 26, 2013 at 3:14 PM, Hans-Peter Diettrich
wrote:
> Alexander Klenin schrieb:
>> 2) Indeed, introducing tuples to Pascal might be an alternative
>> solution. Below is a proposal:
>> 2.1) Tuple definition. Tuple is an anonymous list of values, possibly
>> of different types.
>
>
> OPL: a
On Sat, Jan 26, 2013 at 10:58 PM, Sven Barth
wrote:
>
> I mean less the implementation specific details, but more the syntax they
> chose:
>
> === example begin ===
>
> TTestTuple = tuple of (Integer, String, TObject);
>
> var
> t: TTestTuple;
> i: Integer;
> s: String;
> o: TObject;
> beg
On 26.01.2013 12:55, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
I wonder where you were when Operators feature has been added to
pascal? Or generics?
Generics was implemented without my knowledge. I only found out when
suddenly
the classes unit had been changed to use
On Sat, Jan 26, 2013 at 10:34 PM, Michael Van Canneyt
wrote:
> But if I must choose between
>
> for a,b in c do
>
> (with C a tuple enumerator/iterator) or
>
> for a in c index b do
>
> Then the former is ten times (well, a lot) better.
>
> So if someone were to introduce that to solve the origina
On 26.01.2013 12:52, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 10:50 PM, Sven Barth
wrote:
Generics was implemented without my knowledge. I only found out when
suddenly
the classes unit had been changed to use them. After a horrible
discussion, this was reversed, because of the drop in sp
On 25.01.2013 23:41, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 9:27 AM, Sven Barth wrote:
Regarding tuples:
http://wiki.oxygenelanguage.com/en/Tuples
I know, but I consider this particular implementation an unpleasant example of
"no need to change the language -- lets do it in the libra
In our previous episode, Sven Barth said:
> >> I wonder where you were when Operators feature has been added to
> >> pascal? Or generics?
> >
> > Generics was implemented without my knowledge. I only found out when
> > suddenly
> > the classes unit had been changed to use them. After a horrible
> >
On Sat, Jan 26, 2013 at 10:50 PM, Sven Barth
wrote:
>> Generics was implemented without my knowledge. I only found out when
>> suddenly
>> the classes unit had been changed to use them. After a horrible
>> discussion, this was reversed, because of the drop in speed you got when
>> using generics.
On 26.01.2013 12:34, Michael Van Canneyt wrote:
On Sat, 26 Jan 2013, Paul Ishenin wrote:
26.01.13, 2:32, Michael Van Canneyt пишет:
Pascal is an explicitly declarative language. Anonymous functions go
100% against this. It is the readability horror I associate with
Javascript.
I wonder wh
On Sat, 26 Jan 2013, Paul Ishenin wrote:
26.01.13, 2:32, Michael Van Canneyt пишет:
Pascal is an explicitly declarative language. Anonymous functions go
100% against this. It is the readability horror I associate with
Javascript.
I wonder where you were when Operators feature has been adde
On 25.01.2013 23:57, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 5:17 AM, Sven Barth wrote:
One could also do an alternative (though currently not with arrays, but with
type helper support even that would be possible...):
Yes, this is certainly the most interesting alternative. Actually,
53 matches
Mail list logo
