Paul Ishenin schrieb:
29.01.13, 17:23, Hans-Peter Diettrich пишет:
Paul Ishenin schrieb:
At least it's more fun to implement
something very new, instead of working on incomplete parts (loadable
libraries, targets) which had been delayed due to problems. The same
situation in Lazarus and in m
29.01.13, 17:23, Hans-Peter Diettrich пишет:
Paul Ishenin schrieb:
At least it's more fun to implement
something very new, instead of working on incomplete parts (loadable
libraries, targets) which had been delayed due to problems. The same
situation in Lazarus and in many open source projects
Paul Ishenin schrieb:
At least it's more fun to implement
something very new, instead of working on incomplete parts (loadable
libraries, targets) which had been delayed due to problems. The same
situation in Lazarus and in many open source projects BTW.
Where are your patches for loadable lib
29.01.2013 9:51, Hans-Peter Diettrich wrote:
As a strong argument: you *must* understand everything when you want to
read other people's code, which use the new language features :-(
Only if you want this. And if you want a new feature will not stop you.
Your brains learn something every day a
Paul Ishenin schrieb:
28.01.13, 21:20, Michael Van Canneyt wrote:
Different people see different needs in language. There is nothing bad
not to use and not understand some of the language features.
tatata, you should always understand everything :)
Very weak argument :) In your work you use
On 28 Jan 2013, at 18:00, Alexander Klenin wrote:
> On Tue, Jan 29, 2013 at 12:39 AM, Paul Ishenin wrote:
>>> It offers nothing that objects didn't already have.
>> It offers understandable memory layout without VMT.
> Oops... so, FPC "object" type always creates VMT -- even if there is
> no vir
On Tue, Jan 29, 2013 at 12:39 AM, Paul Ishenin wrote:
>>> I would use anonymouse methods in pascal - I use them in javascript
>>> when I need to perform something asynchronosly.
>>
>>
>> Since you can do the same with simple named methods too, I see no need
>> for creating the readibility horror t
Am 28.01.2013 14:48, schrieb Paul Ishenin:
28.01.13, 21:27, Mattias Gaertner пишет:
You are free to not use a feature, but you must understand all when
using third party code. And the new features are neither easy to
understand nor to remember.
Already replied to Michael. You don't need to un
Am 28.01.2013 14:39, schrieb Paul Ishenin:
I would use anonymouse methods in pascal - I use them in javascript
when I need to perform something asynchronosly.
Since you can do the same with simple named methods too, I see no need
for creating the readibility horror that results of it.
It is
Am 28.01.2013 14:02, schrieb Paul Ishenin:
I scarry to use generics but that simple because they have many bugs.
I'm working on them :(
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinf
28.01.13, 21:51, Michael Van Canneyt пишет:
Enough bickering; it is useless. We will not agree, no matter how many
arguments are presented: simply because the arguments are of a
metaphysical/human/whatever nature, and not technical.
Agreed.
Best regards,
Paul Ishenin
_
On Mon, 28 Jan 2013, Paul Ishenin wrote:
28.01.13, 21:20, Michael Van Canneyt wrote:
Different people see different needs in language. There is nothing bad
not to use and not understand some of the language features.
tatata, you should always understand everything :)
Very weak argument :
28.01.13, 21:27, Mattias Gaertner пишет:
You are free to not use a feature, but you must understand all when
using third party code. And the new features are neither easy to
understand nor to remember.
Already replied to Michael. You don't need to understand third-party
code the same way as y
28.01.13, 21:20, Michael Van Canneyt wrote:
Different people see different needs in language. There is nothing bad
not to use and not understand some of the language features.
tatata, you should always understand everything :)
Very weak argument :) In your work you use system APIs and other
On 01/28/13 13:20, Michael Van Canneyt wrote:
>
> tatata, you should always understand everything :)
:-)
> Since you can do the same with simple named methods too,
> I see no need for creating the readibility horror that results of it.
Yup. I have also seen sample Delphi code where they used
On Mon, 28 Jan 2013 21:02:23 +0800
Paul Ishenin wrote:
> 28.01.13, 20:33, Graeme Geldenhuys пишет:
> > On 01/25/13 08:07, Michael Van Canneyt wrote:
> >> Delphi 7 object pascal could be learned very easily. Nowadays with all the
> >> "features" added
> >> you go, try and explain pascal to someon
In our previous episode, Michael Van Canneyt said:
> > I use avanced record syntax because it makes code more understandable.
>
> It offers nothing that objects didn't already have.
>
> Just trying to say that this is one of these things where Delphi could simply
> have re-instated the TP-style
On Mon, 28 Jan 2013, Paul Ishenin wrote:
28.01.13, 20:33, Graeme Geldenhuys пишет:
On 01/25/13 08:07, Michael Van Canneyt wrote:
Delphi 7 object pascal could be learned very easily. Nowadays with all the
"features" added
you go, try and explain pascal to someone. Say it is 'nice and readabl
28.01.13, 20:33, Graeme Geldenhuys пишет:
On 01/25/13 08:07, Michael Van Canneyt wrote:
Delphi 7 object pascal could be learned very easily. Nowadays with all the
"features" added
you go, try and explain pascal to someone. Say it is 'nice and readable'.
+1
Generics, for-in loops, anonymous m
On 01/25/13 17:17, Alexander Klenin wrote:
>> Using indicies is against all principles of iterators.
> I am not sure what princilpes you are talking about,
The theory. Read any Design Patterns book or technical papers.
> but accessing the key of the current element is required quite often
On th
On 01/25/13 08:07, Michael Van Canneyt wrote:
> If he wants to help, Alexander Klenin had better put his students to useful
> tasks.
>
> There are plenty to choose from.
> He said maybe he'd look after fcl-stl. The silence since was deafening.
> He said he needed a arbitrary precision math libra
On 01/25/13 08:07, Michael Van Canneyt wrote:
> Delphi 7 object pascal could be learned very easily. Nowadays with all the
> "features" added
> you go, try and explain pascal to someone. Say it is 'nice and readable'.
+1
Generics, for-in loops, anonymous methods, classes defined inside
classes e
Am 28.01.2013 10:18, schrieb Michael Schnell:
On 01/25/2013 09:39 PM, Alexander Klenin wrote:
I disagree with the statement that generics are easy to add.
I ANSI C1 I use macros to do what might be done with Generics. (In
fact I'm not really sure that Syntax-based Generics Pascal are more
han
On 01/25/2013 09:39 PM, Alexander Klenin wrote:
I disagree with the statement that generics are easy to add.
I ANSI C1 I use macros to do what might be done with Generics. (In fact
I'm not really sure that Syntax-based Generics Pascal are more handy
(supposedly they are when debugging) )
-M
On 01/25/2013 05:30 PM, Florian Klämpfl wrote:
The idea of iterators is actually to replace and get rid of indicies
because they e.g. fail as soon as the iterated container is changed
during iteration.
To do so, the iterator needs to be notified when an element is added or
deleted. Is this al
2013/1/27 Sven Barth :
> On 27.01.2013 20:46, luiz americo pereira camara wrote:
>>>
>>> What would have been more
>>> interesting is the performance of the generated code compared with e.g. a
>>> TStringList or a TObjectList.
>>
>>
>> Independent of the performance, what's the benefit of replacing
On 27.01.2013 19:09, Michael Van Canneyt wrote:
On Sun, 27 Jan 2013, Sven Barth wrote:
On 27.01.2013 16:27, luiz americo pereira camara wrote:
2013/1/26 Sven Barth :
On 26.01.2013 12:52, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 10:50 PM, Sven Barth
wrote:
Generics was implemente
On 27.01.2013 20:46, luiz americo pereira camara wrote:
What would have been more
interesting is the performance of the generated code compared with e.g. a
TStringList or a TObjectList.
Independent of the performance, what's the benefit of replacing the
current implementation by one based in ge
2013/1/27 Sven Barth :
> On 27.01.2013 16:27, luiz americo pereira camara wrote:
>>
>>
>> I did some test with generics last year:
>> http://lazarusroad.blogspot.com.br/2012/06/cost-of-using-generics.html
>>
>> I would not use in classes unit
>
>
> That's mostly about the "duplication" problem, whi
On Sun, 27 Jan 2013, Sven Barth wrote:
On 27.01.2013 16:27, luiz americo pereira camara wrote:
2013/1/26 Sven Barth :
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
sud
On 27.01.2013 16:27, luiz americo pereira camara wrote:
2013/1/26 Sven Barth :
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
2013/1/26 Sven Barth :
> 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
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
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,
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
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,
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: array of Variant.
Also: Open Array.
Where both are slow and clumsy to use, vio
26.01.13, 4:47, Sven Barth пишет:
I definitely have to disagree here (while still not having an opinion on
the topic "for-in-index" itself): once you've worked on Delphi style
generics you know what messy parsing is... and I already get nightmares
thinking about what I still need to add for Delp
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 added to pascal?
Or generics?
I think now when
In our previous episode, Alexander Klenin said:
> > Probably the main reason for generics was access the 2.0 framework which was
> > new (and used generics) going from D2006 to D2007
>
> Quite probably, but that is still no reason for angular brackets :)
Maybe. But like many extensions, multiple
On Sat, Jan 26, 2013 at 9:50 AM, Marco van de Voort wrote:
>> Whatever the particular syntax, I do agree that the decision to use
>> angular brackets
>> was unnecessarily copied from C++ -- round ones (or, at least, square
>> ones) would be much better.
>
> Delphi got its generics from .NET. The .
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,
anonymous procedures/closures
is the "real" t
In our previous episode, Alexander Klenin said:
> On Sat, Jan 26, 2013 at 9:31 AM, Sven Barth
> wrote:
> > TFPGListLongInt = specialize TFPGList with (Integer);
> >
>
> Whatever the particular syntax, I do agree that the decision to use
> angular brackets
> was unnecessarily copied from C++ --
On Sat, Jan 26, 2013 at 9:31 AM, Sven Barth wrote:
> After implementing support for Delphi style generics I came to the
> conclusion that I would have preferred the following syntax:
>
> type
> TFPGListLongInt = specialize TFPGList as (Integer);
>
> or
>
> type
> TFPGListLongInt = specialize T
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 library" philosophy.
Just look:
>The Tuple type i
On 25.01.2013 23:20, Mark Morgan Lloyd wrote:
Sven Barth wrote:
On 25.01.2013 21:10, Mark Morgan Lloyd wrote:
Something like
for a in a index i do
falls squarely into the latter category: it's messy to parse, worse to
read, and is completely unlike any existing language idioms.
I
On 25.01.2013 22:44, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl wrote:
Where? Concrete code of a serious language! Not some "oh, yes, this
language has it and that as well"
On Sat, Jan 26, 2013 at 7:34 AM, Florian Klämpfl wrote:
No. I want to see a language whi
Sven Barth wrote:
On 25.01.2013 21:10, Mark Morgan Lloyd wrote:
Something like
for a in a index i do
falls squarely into the latter category: it's messy to parse, worse to
read, and is completely unlike any existing language idioms.
I definitely have to disagree here (while still n
On Sat, Jan 26, 2013 at 8:54 AM, Florian Klämpfl wrote:
> Maybe I wouldn't have to ask if there would be a clear proposal what
> shall be implemented, what are alternatives, what do other languages,
> why is a so strange approach chosen etc.
I agree that the quality of initial proposal could be b
On 1/25/2013 13:59, Michael Van Canneyt wrote:
On Sat, 26 Jan 2013, Alexander Klenin wrote:
I certainly agree that Pascal has some advantages -- and they often
outweigh disadvantages.
Otherwise, I would be in Python's mailing list now, arguing to add
some of the Pascal's features :)
However, thi
Am 25.01.2013 22:44, schrieb Alexander Klenin:
> On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl
> wrote:
>> Where? Concrete code of a serious language! Not some "oh, yes, this
>> language has it and that as well"
>
> On Sat, Jan 26, 2013 at 7:34 AM, Florian Klämpfl
> wrote:
>> No. I want to
On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl wrote:
> Where? Concrete code of a serious language! Not some "oh, yes, this
> language has it and that as well"
On Sat, Jan 26, 2013 at 7:34 AM, Florian Klämpfl wrote:
> No. I want to see a language which provides something like the explicit
> i
On 25.01.2013 21:10, Mark Morgan Lloyd wrote:
Something like
for a in a index i do
falls squarely into the latter category: it's messy to parse, worse to
read, and is completely unlike any existing language idioms.
I definitely have to disagree here (while still not having an opinio
On Sat, Jan 26, 2013 at 7:10 AM, Mark Morgan Lloyd
wrote:
> However, I'd suggest that there are two possible category of extension:
> those that implement a clearly-delimited first-class object with interesting
> properties, and those that don't.
>
> Something like a , or a /regular expression/ (b
Am 25.01.2013 21:18, schrieb Alexander Klenin:
> On Sat, Jan 26, 2013 at 6:59 AM, Sven Barth
> wrote:
>>> What is "concrete code"? The code I provided only missed loop bodies.
>>> I can provide that too, but I do not think it will add anything to the
>>> discussion.
>>
>> I believe he wants to ha
On Sat, Jan 26, 2013 at 6:59 AM, Sven Barth wrote:
>> What is "concrete code"? The code I provided only missed loop bodies.
>> I can provide that too, but I do not think it will add anything to the
>> discussion.
>
> I believe he wants to have real world examples (of other languages) where
> this
Sven Barth wrote:
Languages evolve. Natural languages as well as programming languages. We
might not agree with every change (e.g. in German there has been
established the nasty habit of saying "that makes sense" ("das macht
Sinn") while the correct equivalent would be "that has sense" ("das h
On 25.01.2013 20:54, Alexander Klenin wrote:
I have already provided examples.
Where? Concrete code of a serious language! Not some "oh, yes, this
language has it and that as well"
I am afraid that it is very hard for me to discuss against such statements.
Do you consider Java "serious" while
On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl wrote:
> Am 25.01.2013 18:17, schrieb Alexander Klenin:
>>> Using indicies is against all principles of iterators.
>> I am not sure what princilpes you are talking about,
>
> The theory of iterators.
You mean Alexander Stepanov's ideas which served
On 25.01.2013 20:24, Alexander Klenin wrote:
MyDataSet.First;
while not MyDataset.Eof do begin
// ...
MyDataSet.Next;
end;
// on a sidenote: what about a TDataSet enumerator? :)
It is not clear what should loop variable contain:
for v in MyDataSet do ... -- what is v?
Right... forget th
Op Sat, 26 Jan 2013, schreef Alexander Klenin:
On Sat, Jan 26, 2013 at 5:12 AM, Daniël Mantione
wrote:
Consider these arguments:
1) Even for simple arrays, depending on array element type,
and optimizer implementation, for-in can be more efficient since it
can avoid multiplication for eleme
On Sat, Jan 26, 2013 at 6:11 AM, Sven Barth wrote:
> I think he also means things like (without critizing):
Yes, thank for a dose of sanity :)
Few more examples, taken from just one standard package:
while Node.NextBrother<>nil do begin
...
Node:=Node.NextBrother;
end;
while Node<>nil do b
On 25.01.2013 19:59, Michael Van Canneyt wrote:
On Sat, 26 Jan 2013, Alexander Klenin wrote:
Pascal needs more useful libraries.
It is important to note that default libraries ARE part of the language
You are wrong there.
Well, this is a matter of opinion of course, but note that your
opini
On Sat, Jan 26, 2013 at 5:12 AM, Daniël Mantione
wrote:
>> Consider these arguments:
>> 1) Even for simple arrays, depending on array element type,
>> and optimizer implementation, for-in can be more efficient since it
>> can avoid multiplication for element access.
> True, but it shouldn't. Loop
On 25.01.2013 19:32, Michael Van Canneyt wrote:
On Fri, 25 Jan 2013, Sven Barth wrote:
On 25.01.2013 17:18, Alexander Klenin wrote:
With this in mind, consider a user who wants to iterate over the
following array:
var
a: array [1..5] of Integer = (1, 2, 9, 4, 5);
In my proposal, he shou
On Sat, 26 Jan 2013, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 4:38 AM, Michael Van Canneyt
wrote:
WITH EACH ADDITIONAL "FEATURE" WE ARE BUTCHERING PASCAL MORE AND MORE.
Hm... Do not you think this is a bit of an overstatement?
No, not really. I really feel that we are deviating a lo
On 1/25/2013 11:30, Florian Klämpfl wrote:
Am 25.01.2013 17:18, schrieb Alexander Klenin:
var
a: array [1..5] of Integer = (1, 2, 9, 4, 5);
In my proposal, he should write:
var
v, i: Integer;
begin
for a in a index i do
Writeln(i, ' ', v);
end.
In this case I just write
for i:=
On Sat, Jan 26, 2013 at 4:38 AM, Michael Van Canneyt
wrote:
>>> WITH EACH ADDITIONAL "FEATURE" WE ARE BUTCHERING PASCAL MORE AND MORE.
>> Hm... Do not you think this is a bit of an overstatement?
> No, not really. I really feel that we are deviating a lot from what pascal
> stands for.
If you me
On Fri, 25 Jan 2013, Sven Barth wrote:
On 25.01.2013 17:18, Alexander Klenin wrote:
With this in mind, consider a user who wants to iterate over the
following array:
var
a: array [1..5] of Integer = (1, 2, 9, 4, 5);
In my proposal, he should write:
var
v, i: Integer;
begin
for a in
Am 25.01.2013 18:17, schrieb Alexander Klenin:
> On Sat, Jan 26, 2013 at 3:30 AM, Florian Klämpfl
> wrote:
>>> "for-in-index" extension was actually planned by me as a prerequisite
>>> for fcl-stl work.
>>
>> Using indicies is against all principles of iterators.
> I am not sure what princilpes y
On 25.01.2013 17:18, Alexander Klenin wrote:
With this in mind, consider a user who wants to iterate over the
following array:
var
a: array [1..5] of Integer = (1, 2, 9, 4, 5);
In my proposal, he should write:
var
v, i: Integer;
begin
for a in a index i do
Writeln(i, ' ', v);
end.
Op Sat, 26 Jan 2013, schreef Alexander Klenin:
var
a: array [1..5] of Integer = (1, 2, 9, 4, 5);
In my proposal, he should write:
var
v, i: Integer;
begin
for v in a index i do
Writeln(i, ' ', v);
end.
In this case I just write
for i:=low(a) to high(a) do
writeln(i,' ',a[i]);
Michael Schnell schrieb:
On 01/25/2013 10:52 AM, Mattias Gaertner wrote:
The above UTF8 example misses some points
My question was about the want for a construct that allows for accessing
the n'th printable character in an UTF-8 string
Everybody can write such a subroutine, when really ne
1 - 100 of 167 matches
Mail list logo
