On 25.01.2013 23:57, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 5:17 AM, Sven Barth pascaldra...@googlemail.com 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
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
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
On Sat, Jan 26, 2013 at 10:50 PM, Sven Barth
pascaldra...@googlemail.com 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
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
discussion,
On 25.01.2013 23:41, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 9:27 AM, Sven Barth pascaldra...@googlemail.com 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
On 26.01.2013 12:52, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 10:50 PM, Sven Barth
pascaldra...@googlemail.com 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
On Sat, Jan 26, 2013 at 10:34 PM, Michael Van Canneyt
mich...@freepascal.org 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
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:58 PM, Sven Barth
pascaldra...@googlemail.com 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:
On Sat, Jan 26, 2013 at 3:14 PM, Hans-Peter Diettrich
drdiettri...@aol.com 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.
On Sat, 26 Jan 2013, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 10:50 PM, Sven Barth
pascaldra...@googlemail.com 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
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.
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
On Sat, 26 Jan 2013, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 10:34 PM, Michael Van Canneyt
mich...@freepascal.org 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.
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
On Sun, Jan 27, 2013 at 12:26 AM, Paul Ishenin paul.ishe...@gmail.com 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
On 26.01.2013 15:52, Alexander Klenin wrote:
On Sun, Jan 27, 2013 at 12:26 AM, Paul Ishenin paul.ishe...@gmail.com wrote:
26.01.13, 6:57, Alexander Klenin пишет:
Why to invent a new solution if Delphi already have one:
On Sat, Jan 26, 2013 at 4:57 PM, Sven Barth pascaldra...@googlemail.com wrote:
On 26.01.2013 15:52, Alexander Klenin wrote:
On Sun, Jan 27, 2013 at 12:26 AM, Paul Ishenin paul.ishe...@gmail.com
wrote:
26.01.13, 6:57, Alexander Klenin пишет:
Why to invent a new solution if Delphi already
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.
As
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.
On Sun, Jan 27, 2013 at 1:59 AM, kyan alfasud...@gmail.com 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
On Sun, Jan 27, 2013 at 1:05 AM, Mark Morgan Lloyd
markmll.fpc-de...@telemetry.co.uk 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.
On 26.01.2013 16:34, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 8:31 PM, Sven Barth pascaldra...@googlemail.com 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, '
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 at the
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 Sun, Jan 27, 2013 at 3:10 AM, Sven Barth pascaldra...@googlemail.com 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
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
42 matches
Mail list logo
