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
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
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
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) )
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
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
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 library:
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 the
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
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
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 21:02:23 +0800
Paul Ishenin paul.ishe...@gmail.com 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
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
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
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
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: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
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
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
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
On Tue, Jan 29, 2013 at 12:39 AM, Paul Ishenin paul.ishe...@gmail.com 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
On 28 Jan 2013, at 18:00, Alexander Klenin wrote:
On Tue, Jan 29, 2013 at 12:39 AM, Paul Ishenin paul.ishe...@gmail.com 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
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
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
2013/1/26 Sven Barth pascaldra...@googlemail.com:
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
On 27.01.2013 16:27, luiz americo pereira camara wrote:
2013/1/26 Sven Barth pascaldra...@googlemail.com:
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
On Sun, 27 Jan 2013, Sven Barth wrote:
On 27.01.2013 16:27, luiz americo pereira camara wrote:
2013/1/26 Sven Barth pascaldra...@googlemail.com:
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
2013/1/27 Sven Barth pascaldra...@googlemail.com:
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
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
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 pascaldra...@googlemail.com:
On 26.01.2013 12:52, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 10:50 PM, Sven Barth
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
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
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 Fri, 25 Jan 2013, Paul Ishenin wrote:
25.01.2013 11:47, Василий Кевролетин пишет:
May be you understood what I'm from university in wrong way. It does
*not* mean what I need to quickly do any changes anywhere. It means what
I have resources /(time, motivation, direct support of very good
On 01/25/13 00:11, Alexander Klenin wrote:
Do I understand correctly that you are speaking about this article:
http://opensoft.homeip.net/articles/iterator_pattern.pdf ?
Yes.
As far as I understand, since iterators described in the article do
not have the concept of a current item,
The
On Fri, 25 Jan 2013, Alexander Klenin wrote:
On Fri, Jan 25, 2013 at 9:36 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
If you want full fledged iterators, use classes.
Please provide example of your suggestion for the case in the wiki.
I don't need to provide *anything*.
Of
On Friday 25 January 2013 09:07:27 Michael Van Canneyt wrote:
Once more: simple is beautiful.
Free pascal becomes less so with each of these features.
Agreed. I even would say it becomes more by removing some of the
existing features. ;-)
Martin
On Fri, 25 Jan 2013, Martin Schreiber wrote:
On Friday 25 January 2013 09:07:27 Michael Van Canneyt wrote:
Once more: simple is beautiful.
Free pascal becomes less so with each of these features.
Agreed. I even would say it becomes more by removing some of the
existing features. ;-)
Michael Van Canneyt mich...@freepascal.org hat am 25. Januar 2013 um 09:26
geschrieben:
[...]
You are totally missing the point.
Finding a use case to justify a feature is not difficult.
I could probably find some more use cases to justify other 'missing features'.
The point is: it is not
On Fri, 25 Jan 2013, Mattias Gaertner wrote:
Michael Van Canneyt mich...@freepascal.org hat am 25. Januar 2013 um 09:26
geschrieben:
[...]
You are totally missing the point.
Finding a use case to justify a feature is not difficult.
I could probably find some more use cases to justify other
On 01/23/2013 12:54 AM, vrt277 wrote:
Hi FPC team,
There is good proposed extension of for-in loop on fpc wiki: get
enumerator Position if available
http://wiki.freepascal.org/for-in_loop#Proposed_extensions. From my
point of view it's essential part of iterators. Especially for data
In our previous episode, Mattias Gaertner said:
In general: +1
Even the common syntax highlighters have trouble. I don't know if Delphi's
syntax highlighter understand their language fully.
Exhibit A: http://qc.embarcadero.com/wc/qcmain.aspx?d=107289
In our previous episode, Martin Schreiber said:
Once more: simple is beautiful.
Free pascal becomes less so with each of these features.
Agreed. I even would say it becomes more by removing some of the
existing features. ;-)
Indeed. I went to look at the generic classes during the
Michael Schnell mschn...@lumino.de hat am 25. Januar 2013 um 10:35
geschrieben:
On 01/23/2013 12:54 AM, vrt277 wrote:
Hi FPC team,
There is good proposed extension of for-in loop on fpc wiki: get
enumerator Position if available
Mattias Gaertner nc-gaert...@netcologne.de hat am 25. Januar 2013 um 10:52
geschrieben:
Michael Schnell mschn...@lumino.de hat am 25. Januar 2013 um 10:35
geschrieben:
On 01/23/2013 12:54 AM, vrt277 wrote:
Hi FPC team,
There is good proposed extension of for-in loop on fpc wiki:
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
Finding the 10 th and then independently the 15 th printable
On Fri, 25 Jan 2013, Michael Schnell wrote:
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
Finding the 10 th and then
On 01/25/2013 11:12 AM, Michael Van Canneyt wrote:
Pchar ?
You seem to miss my point: the n'th printable character in an utf-8
coded string (may same be stored as a pchar or a string) starts at the
m'th byte (m=n).
To find m for a given n you need to scan all bytes m.
Thus a loop such as
Michael Schnell mschn...@lumino.de hat am 25. Januar 2013 um 11:09
geschrieben:
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
On Fri, 25 Jan 2013, Michael Schnell wrote:
On 01/25/2013 11:12 AM, Michael Van Canneyt wrote:
Pchar ?
You seem to miss my point: the n'th printable character in an utf-8 coded
string (may same be stored as a pchar or a string) starts at the m'th byte
(m=n).
I know that.
To find m
Michael Schnell mschn...@lumino.de hat am 25. Januar 2013 um 11:22
geschrieben:
On 01/25/2013 11:12 AM, Michael Van Canneyt wrote:
Pchar ?
You seem to miss my point: the n'th printable character in an utf-8
coded string (may same be stored as a pchar or a string) starts at the
m'th byte
Op Fri, 25 Jan 2013, schreef Michael Schnell:
On 01/25/2013 11:12 AM, Michael Van Canneyt wrote:
Pchar ?
You seem to miss my point: the n'th printable character in an utf-8 coded
string (may same be stored as a pchar or a string) starts at the m'th byte
(m=n).
To find m for a given n
On 01/25/2013 11:27 AM, Michael Van Canneyt wrote:
Yes, but this is random access in a string.
Enumerators will not help you with random access, only with sequential
access.
This is why I put enumerator in , and in this discussion you already
said that the OP did not really meant to talk
In our previous episode, Michael Schnell said:
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
Printable rendering depends on font and display properties.
On 01/25/2013 11:36 AM, Mattias Gaertner wrote:
Maybe real world examples would be better to prove a point.
The real world in fact does not need computers.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Fri, 25 Jan 2013, Michael Schnell wrote:
On 01/25/2013 11:27 AM, Michael Van Canneyt wrote:
Yes, but this is random access in a string.
Enumerators will not help you with random access, only with sequential
access.
This is why I put enumerator in , and in this discussion you already
On 01/25/2013 11:39 AM, Daniël Mantione wrote:
Yes, it is a known fact that this is a weakness of UTF-8.
Maybe you should say its a feature.
Consider transforming the string to UTF-16, UTF-32 or even an internal
datastructure before doing the random access.
This has been already discussed
Michael Schnell mschn...@lumino.de hat am 25. Januar 2013 um 11:58
geschrieben:
On 01/25/2013 11:23 AM, Mattias Gaertner wrote:
Do you mean codepoint? Printable depends on ligatures and other things.
Both might be desirable. I don't want to define that. This will depend
´on the
Hi,
though not a fpc developer, I strongly want to support Michaels opinion
(not specifically addressing this feature).
For me Pascal is the language of choice because of its readability and
strictness and simple / clean syntax.
IMO C++ actually evolved C in exactly this direction.
Therefore it
On 01/25/13 10:22, Michael Schnell wrote:
and replacing the term myString[n] by a
straight forward function searching for the n'th printable character
will be very slow.
And I am yet to see a real-world example where this is needed. ALL
examples I have seen, the developer was already busy
On 01/25/13 10:40, Michael Schnell wrote:
The real world in fact does not need computers.
Huh?
G.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 01/25/2013 04:38 PM, Paul Ishenin wrote:
You need to look at another Michael mail where he claims that he was
against for-in loop feature when it had going to be implemented. So no
suprise that he is against extending it now.
Michael, please don't demotivate our potential compiler
On 01/25/13 10:51, Michael Schnell wrote:
A decent smart indexer class with appropriate enumerator/iterator-like
compiler-magic syntax might help until then and is a lot nicer than the
old-fashioned myString[i] notation anyway, on top of being compatible
with any future string
On 01/26/2013 12:27 AM, Michael Van Canneyt wrote:
You are new on the list, and so probably do not know this, but I hate
wikis.
Wikis are - by and large - a perfect example of what goes wrong in IT
and in Open Source:
Lots of things get started. Few are actually finished.
Probably you think
On Sat, 26 Jan 2013, vrt277 wrote:
On 01/26/2013 12:27 AM, Michael Van Canneyt wrote:
You are new on the list, and so probably do not know this, but I hate
wikis.
Wikis are - by and large - a perfect example of what goes wrong in IT and
in Open Source:
Lots of things get started. Few are
On Fri, Jan 25, 2013 at 7:07 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
WITH EACH ADDITIONAL FEATURE WE ARE BUTCHERING PASCAL MORE AND MORE.
Hm... Do not you think this is a bit of an overstatement?
There are plenty to choose from. He said maybe he'd look after fcl-stl. The
silence
Am 25.01.2013 15:20, schrieb Michael Van Canneyt:
But they are all practical things you need in everyday programming
to solve programming tasks you will get when you work in an IT
company. But these are probably not very interesting from an
academic point of view...
Why not? A mechanism to
Am 25.01.2013 17:18, schrieb Alexander Klenin:
On Fri, Jan 25, 2013 at 7:07 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
WITH EACH ADDITIONAL FEATURE WE ARE BUTCHERING PASCAL MORE AND MORE.
Hm... Do not you think this is a bit of an overstatement?
There are plenty to choose from.
Op Sat, 26 Jan 2013, schreef Alexander Klenin:
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.
Am 25.01.2013 17:18, schrieb Alexander Klenin:
He said he needed a arbitrary precision math library: Well, get started !
I have chosen a good library, communicated with the author, and he
agreed (on this list)
to allow its inclusion in FPC. Now somebody (not me, since I do not
have commit
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
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]);
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);
Am 25.01.2013 18:17, schrieb Alexander Klenin:
On Sat, Jan 26, 2013 at 3:30 AM, Florian Klämpfl flor...@freepascal.org
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
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
On Sat, Jan 26, 2013 at 4:38 AM, Michael Van Canneyt
mich...@freepascal.org 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
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
On Sat, 26 Jan 2013, Alexander Klenin wrote:
On Sat, Jan 26, 2013 at 4:38 AM, Michael Van Canneyt
mich...@freepascal.org 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
1 - 100 of 141 matches
Mail list logo
