subject:"Re\: \[fpc\-devel\] for\-in\-index loop"


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 
handy (supposedly they are  when debugging) )
I've written a macro based list type for a C based project in 
university... I'm definitely in favor of a real generic syntax like it's 
implemented in FPC.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

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 etc... I have and see no need for them, and they simply
complicate the beautiful Object Pascal language (at least from the D7 days).


Regards,
  - Graeme -

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

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: Well, get started !
 Both should be perfectly within grasp of a student.
 If he has students, let them work on that.

+1

To add to that list... a native Free Pascal Debugger. I'm already
working on this in my [very limited] spare time. Progress is slow, but
progress is being made. The debugger is based on reading the DWARF debug
information that FPC generates.


Regards,
  - Graeme -

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

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 contrary. You should be interested in the current element, not
the index value it represents. ALL my iterators in all my application
code don't use or need the index value. I simply ask for the Next or
Previous object or value.

This also hides the implementation details of the container object, thus
the container can change its internal implementation, and my Iterator
code in my applications will still continue to function without change.


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 methods, classes defined inside
classes etc... I have and see no need for them, and they simply
complicate the beautiful Object Pascal language (at least from the D7 days).


Different people see different needs in language. There is nothing bad 
not to use and not understand some of the language features.


I used for-in loop many times in my applications simple because it 
reduce the code and therefore makes it more readable.


I also used types inside classes - this is a great feature. I don't need 
to polute global namespace with internal types.


I would use anonymouse methods in pascal - I use them in javascript when 
I need to perform something asynchronosly.


I use avanced record syntax because it makes code more understandable.

I scarry to use generics but that simple because they have many bugs.

Best regards,
Paul Ishenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-28 Thread Michael Van Canneyt




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 readable'.


+1

Generics, for-in loops, anonymous methods, classes defined inside
classes etc... I have and see no need for them, and they simply
complicate the beautiful Object Pascal language (at least from the D7 
days).


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 :)



I used for-in loop many times in my applications simple because it reduce the 
code and therefore makes it more readable.


I also used types inside classes - this is a great feature. I don't need to 
polute global namespace with internal types.


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.



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 objects. The compiler compiled them anyway already.

There was no need to burden records with methods in an attempt to make them 
'object-like'.

Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-28 Thread Marco van de Voort

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 objects. The compiler compiled them anyway 
 already.
 There was no need to burden records with methods in an attempt to make them 
 'object-like'.

I think it works the other way around, creating room to deprecate TP objects
in time. 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-28 Thread Mattias Gaertner

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 to someone. Say it is 'nice and readable'.
 
  +1
 
  Generics, for-in loops, anonymous methods, classes defined inside
  classes etc... I have and see no need for them, and they simply
  complicate the beautiful Object Pascal language (at least from the D7 days).
 
 Different people see different needs in language. There is nothing bad 
 not to use and not understand some of the language features.

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.

 
 I used for-in loop many times in my applications simple because it 
 reduce the code and therefore makes it more readable.

True.
But it adds quite a lot of stuff and a simple loop can become much
slower.

 
 I also used types inside classes - this is a great feature. I don't need 
 to polute global namespace with internal types.

True. What about nested classes?

 
 I would use anonymouse methods in pascal - I use them in javascript when 
 I need to perform something asynchronosly.

Correct me if I'm wrong, but all the alternatives in javascript have
some drawbacks, you don't write big programs in
javascript and the anonymous methods easily confuse the javascript
debuggers.

 
 I use avanced record syntax because it makes code more understandable.

This feature made records more consistent with objects and classes, so
I would say they indeed made Pascal easier to understand.

 
 I scarry to use generics but that simple because they have many bugs.


Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

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 Generics. It
was on the Code of Horror website if I remember correctly. It was
ridiculously complex, unreadable, and probably a nightmare to debug. I
regard simplicity and readability very high in my code. It makes working
in a team so much easier too. That is what the Pascal language was all
about.


 I use avanced record syntax because it makes code more understandable.
 
 It offers nothing that objects didn't already have.

Yeah, what was that all about... advanced records. They are nothing
more than the Objects introduced in Turbo Pascal days - and then
Embarcadero has the audacity to call it a new language feature. LOL.

BTW: I still find it useful using Objects instead of Classes in some
places in my code.


Regards,
  - Graeme -

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 
frameworks which are made in C, C++ or assembler. I believe you don't 
understand everything and if you don't - you use the reference if 
needed. The same way with pascal - if you don't want to learn new 
features then use libraries as black boxes but if you need then use a 
reference.




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 a readability horror when for injecting a small piece of code as 
anonymouse method in place where it is needed you *must* declare a new 
named method (which will no be used anywhere else) few screens up or down.



It offers nothing that objects didn't already have.


It offers understandable memory layout without VMT.


Just trying to say that this is one of these things where Delphi could
simply have re-instated the TP-style objects. The compiler compiled them
anyway already.
There was no need to burden records with methods in an attempt to make
them 'object-like'.


Best regards,
Paul Ishenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 you don't need to understand API sources. For 
winapi and cocoa you don't even have the sources to understand something.



True.
But it adds quite a lot of stuff and a simple loop can become much
slower.


True. Classes adds quite a lot of stuff and simple procedures can become 
much slower. Let's don't use them.



I also used types inside classes - this is a great feature. I don't need
to polute global namespace with internal types.


True. What about nested classes?


Class is just one of the types pascal have. If for some reason you need 
to use internal class - use it. But in my practive I mostly need some 
enumerations.



I would use anonymouse methods in pascal - I use them in javascript when
I need to perform something asynchronosly.


Correct me if I'm wrong, but all the alternatives in javascript have
some drawbacks, you don't write big programs in
javascript and the anonymous methods easily confuse the javascript
debuggers.


You can use named methods too wihout drawbacks. Of course one of the 
benefits of anonymouse methods is javascript is access to local 
variables. And I don't notice that chrome debugger is confused much by them.


Best regards,
Paul Ishenin

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-28 Thread Michael Van Canneyt

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 :) In your work you use system APIs and other frameworks
which are made in C, C++ or assembler. I believe you don't understand
everything and if you don't - you use the reference if needed. The same way
with pascal - if you don't want to learn new features then use libraries as
black boxes but if you need then use a reference.

I can understand the argument for libraries, but not for the programming
language itself.

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 a readability horror when for injecting a small piece of code as
anonymouse method in place where it is needed you *must* declare a new named
method (which will no be used anywhere else) few screens up or down.

Absolutely. You have local procedures for exactly this reason.
That is what Pascal stands for.

I use Anonymous methods in Javascript too, but in the majority of cases I
end up naming them anyway.

So I do not think the use case justifies the mutilation.

It offers nothing that objects didn't already have.

It offers understandable memory layout without VMT.

That could have been solved with a simple novmt' keyword just like the existing
'packed'. There, I could have saved Embarcadero lots of valuable time with that :-)

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.

Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 a readability horror when for injecting a small piece of code as 
anonymouse method in place where it is needed you *must* declare a new 
named method (which will no be used anywhere else) few screens up or 
down.


I agree here. Also think about e.g. Synchronize. You must create a 
parameterless method + fields for each method you want to execute in the 
main thread. Here I definitely prefer anonymous methods.  And an also 
important aspect of them is that they can capture variable state from 
outside it's body. You can't do the exact same with nested procedures...


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 understand third-party 
code the same way as you don't need to understand API sources. For 
winapi and cocoa you don't even have the sources to understand something.

For WinAPI: Wine/ReactOS
For Cocoa: GNUStep

:)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-28 Thread Alexander Klenin

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 horror that results of it.


 It is a readability horror when for injecting a small piece of code as
 anonymouse method in place where it is needed you *must* declare a new named
 method (which will no be used anywhere else) few screens up or down.

Note that readability troubles of anonymous functions in Pascal
are largely due to unfortunate syntax.
In a parallel thread, I have offered some suggestions to make them
much more readable.

 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 virtual methods?

-- 
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-28 Thread Jonas Maebe


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 there is
 no virtual methods?

Not always, but there are other conditions when a VMT is generated for objects, 
just like in Delphi/TP: when a constructor or destructor exists. In general, 
I'd also strongly recommend to treat them as opaque types, especially because 
this VMT may be inserted in the middle of the object, and be subject to special 
alignment requirements because of the target (regardless of the current 
{$packrecords x} or packed setting).


Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-28 Thread Hans-Peter Diettrich


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 system APIs and other 
frameworks which are made in C, C++ or assembler. I believe you don't 
understand everything and if you don't - you use the reference if 
needed. The same way with pascal - if you don't want to learn new 
features then use libraries as black boxes but if you need then use a 
reference.


As a strong argument: you *must* understand everything when you want to 
read other people's code, which use the new language features :-(



IMO most of the new features had been added *only* for .NET 
compatibility. But since Delphi.NET is dead, I see no need to introduce 
them into FPC, where .NET never was on topic. But I understand that the 
compiler developers need something to put their hands on, so that the 
new language features come in at the right time. The Delphi developers 
had a goal (.NET) and limited time, while the FPC developers have time 
and look out for new goals. 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.


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 anyway. And I believe that the 
majority of features which you touch below are easy to learn and 
understand. At least it must be much easier to learn and understand than 
code from fpc\rtl\i386 which nobody complains about.



IMO most of the new features had been added *only* for .NET
compatibility. But since Delphi.NET is dead, I see no need to introduce
them into FPC, where .NET never was on topic. But I understand that the
compiler developers need something to put their hands on, so that the
new language features come in at the right time. The Delphi developers
had a goal (.NET) and limited time, while the FPC developers have time
and look out for new goals.



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 libraries and new targets?

Best regards,
Paul Ishenin

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-27 Thread luiz americo pereira camara

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 use them. After a horrible
 discussion, this was reversed, because of the drop in speed you got when
 using generics.


 Ah! So that is where those ifdefs in classes come from :) I always
 wondered...

 Is the drop still present/essential? Perhaps optimizer is now good
 enough to drop those ifdefs?


 Someone would need to test this. It could be that the generic variant is
 less optimal, because the generic list is built upon a list that handles
 pointers...


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

Luiz
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-27 Thread Sven Barth


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 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.



Ah! So that is where those ifdefs in classes come from :) I always
wondered...


Is the drop still present/essential? Perhaps optimizer is now good
enough to drop those ifdefs?



Someone would need to test this. It could be that the generic variant is
less optimal, because the generic list is built upon a list that handles
pointers...



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, which is known (maybe 
I'll try to improve the situation some time). What would have been more 
interesting is the performance of the generated code compared with e.g. 
a TStringList or a TObjectList.


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-27 Thread Michael Van Canneyt

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 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.

Ah! So that is where those ifdefs in classes come from :) I always
wondered...

Is the drop still present/essential? Perhaps optimizer is now good
enough to drop those ifdefs?

Someone would need to test this. It could be that the generic variant is
less optimal, because the generic list is built upon a list that handles
pointers...

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, which is known (maybe I'll try
to improve the situation some time). What would have been more interesting is
the performance of the generated code compared with e.g. a TStringList or a
TObjectList.

When I tested it, there was a 10% slowdown.
It is the difference between a direct pointer assignment vs. calling Move() for each assignment.

Regardless, I don't see the need of replacing proven code with generics just as a
showcase for generics. If it ain't broken, don't fix it.

Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-27 Thread luiz americo pereira camara

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 problem, which is known (maybe I'll
 try to improve the situation some time).

OK

 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 generic?

AFAIK none. It would just require more work, resulting in bigger and slower code

BTW: i use generic myself but mostly in application code. I avoid in
components / libraries

Luiz
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-27 Thread 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 the
current implementation by one based in generic?

AFAIK none. It would just require more work, resulting in bigger and slower code


I'm not saying that we should replace the code in Classes by generics. 
I'm just interested in how generics perform compared to non-generic 
generic classes.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-27 Thread Sven Barth


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
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
using generics.



Ah! So that is where those ifdefs in classes come from :) I always
wondered...


Is the drop still present/essential? Perhaps optimizer is now good
enough to drop those ifdefs?



Someone would need to test this. It could be that the generic
variant is
less optimal, because the generic list is built upon a list that
handles
pointers...



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, which is known (maybe
I'll try to improve the situation some time). What would have been
more interesting is the performance of the generated code compared
with e.g. a TStringList or a TObjectList.


When I tested it, there was a 10% slowdown. It is the difference between
a direct pointer assignment vs. calling Move() for each assignment.



I just checked the code of TFPGList. It does not use Move if you look at 
it correctly:


TFPGList.Add calls TFPSList.Add with the address of the argument.
TFPSList.Add in turn (basically) calls TFPSList.CopyItem which (in so 
far you are right) is implemented using Move. But this method is virtual 
and overridden in TFPGList where it's an assignment between dereferenced 
pointers to the generic type T.


But maybe it would still be faster if TFPGList would not be derived from 
TFPSList, but completely implement the list handling itself with an 
array of T and using just assignments. It could be that all those 
virtual method calls are the problem here...



Regardless, I don't see the need of replacing proven code with generics
just as a showcase for generics. If it ain't broken, don't fix it.


As I just wrote to luiz: I'm not suggesting to change anything in 
Classes regarding usage of generics. I'm just curious regarding their 
performance behavior.


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: Anonymous procedures (Was: Re: [fpc-devel] for-in-index loop)


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 interesting alternative. Actually,
anonymous procedures/closures
is the real task I wanted Vasily to perform, after the warm-up of
for-in-index.


Just in case: we already have a branch where someone started the 
development for anonymous functions some months ago. You can find it here:


http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/blaise/closures/

Please Note: the branch currently won't compile as the unit pnameless 
is missing. I've asked the author whether he wants to continue his work 
or if he could at least leave the branch in a compiling state. I'm still 
waiting for an answer (he confirmed me though that he got my mail and 
that he'll answer me when he finds the time).



You have also proposed lambda-expressions:

map.Iterate(lambda TFPGMapLongInt.TIteratorProc(aKey, aData) as Writeln(aKey, ' 
= ', aData.ClassName));


I think that they are not optimal in the proposed form.
Note that the longest part of the expression is actually a restatement
of the Iterate parameter type.
I propose to allow omitting that:

map.Iterate(lambda begin
   Writeln(aKey, ' = ', aData.ClassName);
end;)

That is, basically, lambda means use procedure definition from the
parameter type.


I have already thought about this as well, but this is simply not how 
Pascal (and especially the compiler) works. In Pascal the result of an 
expression is (at first) independantly of the result it is assigned to. 
For example:


double1 := 1.0/2.0;

here the expression on the right side will be evaluated with the 
smallest possible precision that does not cause data loss (let's assume 
for now that 1.0, 2.0 and 0.5 all can be represented by a Single) and 
only in the assignment the result is converted to a Double.


Also there's the problem of overloaded procedures. Let's assume we have

type
  TProc1 = reference of procedure(aArg: Integer);
  TProc2 = reference of procedure(aArg: String);

procedure SomeProc(aArg: TProc1);
procedure SomeProc(aArg: TProc2);

SomeProc(lambda as Writeln(aArg));

Which SomeProc to choose? Even if the lamda's code could derive the 
argument types directly (which must not be the case as you can see in 
the example, as Writeln can take an Integer as well as a String) you'd 
still need to find the correct procedure.


Also the parameter names MUST be declared somewhere. This is Pascal. 
There can't be a symbol name appearing suddenly in the middle of the code.


These three points are why I proposed my example as is: we need somehow 
the signature of the lambda. Maybe lambda(aArg: Integer) as 
Writeln(aArg) would be sufficient already (or lambda(aArg: Integer): 
String as IntToStr(aArg) for a function).


Otherwise - to borrow a statement from the for-in-index thread - we 
would be butchering Pascal.




Independently, I propose a general shorthand for functions containing
a single expression
(and perhaps for procedures containing a single statement, but I am
less certain here):

function f(a, b: Integer): Integer;
begin Result := a + b; end;
=
function f(a, b: Integer): Integer as a + b;



I don't know whether I'd want to extend this to single line 
functions/procedures. This is where the language becomes less clear again.



with both shortcuts combined, it becomes possible to write something like

sum := arr.Reduce(lambda as a + b;);

Even further, Ruby (or Objective C)-like extension may be introduced to allow
procedure arguments (or perhaps just the last one) to be separated by
some special character instead of parenthesis, for example:


No, no, no. No special characters. If you want to differentiate 
something, then use keywords.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop




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 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, this 
was reversed, because of the drop in speed you got when using generics.


Operators are a natural thing:
Pascal defines some basic types and operations on them.
Pascal allows you to define extra types, so it is natural 
that it allows you to define these operations on them.


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 less explicit for sure.


Personally, I think the tuple approach proposal is more general, and therefor 
better.

Once more, I do not think that language extensions are bad. 
I judge them on a case by case basis.


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 original poster's problem, 
you will not hear me protesting, it will have been well worth the energy 
I put in this discussion.


Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 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, this was reversed, because of the drop in speed you got when
using generics.


Ah! So that is where those ifdefs in classes come from :) I always 
wondered...


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

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
 using generics.

 Ah! So that is where those ifdefs in classes come from :) I always
 wondered...

Is the drop still present/essential? Perhaps optimizer is now good
enough to drop those ifdefs?

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-26 Thread Marco van de Voort

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, this was reversed, because of the drop in speed you got when
  using generics.
 
 Ah! So that is where those ifdefs in classes come from :) I always 
 wondered...

Moreover, Delphi's generic TList is in generics.collections, not in classes.

There is no tstringlist, they went with a Dictionary instead.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 -- lets do it in the library philosophy.
Just look:

The Tuple type is a set of generic types with 1 up to 7 generic parameter types 
for the value types.
There also is an 8th Tuple type of which the 8th parameter type has to be 
another tuple.


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;
begin
  t := (42, 'Hello World', TObject.Create); // ok, this can be 
considered nightmarish syntax again... (see below)

  (i, s, o) := t;
  // and yes this could also provide the possibility for multiassignments
  (i, s, o) := (42, 'Hello World', TObject.Create);
end;

=== example end ===

The only thing I have a problem with is to use (...) as the syntax 
element for tuples... e.g. is (42) an integer or a tuple of 
(Integer)? We'd need to either enforce that tuple of (...) needs an 
element count  1 or that tuple of (SomeType) is assignment compatible 
to just SomeType (we'd need something like this, because of backwards 
compatibility).


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 reversed, because of the drop in speed you got when
using generics.


Ah! So that is where those ifdefs in classes come from :) I always
wondered...


Is the drop still present/essential? Perhaps optimizer is now good
enough to drop those ifdefs?


Someone would need to test this. It could be that the generic variant is 
less optimal, because the generic list is built upon a list that handles 
pointers...


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

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 the original poster's problem,
 you will not hear me protesting, it will have been well worth the energy I
 put in this discussion.


There are two reasons I proposed latter instead of former:
1) I think using keyword is more explicit and readable
2) I thought that smaller feature is easier to argue for than a large one --
  apparently, I was mistaken on that :)

So, amended for-in-index proposal:
1) The syntax is
for value, key in container do ...
2) The enumerator interface is extended with optional
property CurrentWithKey: TValueKey;
where TValueKey must be a record with two fields.
This property will be called in the case of two-argument for-in,
while the case of single-argument for-in continues to work as-is
for both compatibility and efficiency.
3) When/if the full tuple proposal gets implemented, for-in-index,
now aka for-key-in, will became a proper subset of it.

What do you think?

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 them. After a horrible
discussion, this was reversed, because of the drop in speed you got when
using generics.


Ah! So that is where those ifdefs in classes come from :) I always
wondered...


Moreover, Delphi's generic TList is in generics.collections, not in classes.



Luckily we don't have a generic TList at all yet ^^


There is no tstringlist, they went with a Dictionary instead.


Which reminds me that I wanted to port Python's dictionary 
implementation which is said to be the fastest around :)


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

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: TObject;
 begin
   t := (42, 'Hello World', TObject.Create); // ok, this can be considered
 nightmarish syntax again... (see below)
   (i, s, o) := t;
   // and yes this could also provide the possibility for multiassignments
   (i, s, o) := (42, 'Hello World', TObject.Create);
 end;

 === example end ===

 The only thing I have a problem with is to use (...) as the syntax element
 for tuples... e.g. is (42) an integer or a tuple of (Integer)? We'd need
 to either enforce that tuple of (...) needs an element count  1 or that
 tuple of (SomeType) is assignment compatible to just SomeType (we'd need
 something like this, because of backwards compatibility).


Note that my proposal specifically forbids to create named tuples,
because named tuples are just records :)
As for syntax ambiguity -- I agree it is a problem. Perhaps a symbol
to denote tuple could be chosen
(e.g. @@), and is required in front of *all* tuples:
@@(a, b) = @@(b, c);
@@(first, second) = @@FunctionReturningArray;
ProcWithmanyParams(@@p);
... etc
unfortunately, this will also require
for @@(v, i) in a do
which is not nice.

Another possibility is to resolve single element in brackets in favor
of a simple value, and require explicit call to Tuple
to disambiguate -- single-element tuples are useless anyway, so will be rare.

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

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.


 OPL: array of Variant.
 Also: Open Array.

 Where both are slow and clumsy to use, violating the principle of
 strictly typed languages.

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).

As for array of Vaiant and array of const -- they are very different
from the tuples proposal.
Note that tuples proposal is carefully constructed in such a way that
tuples are statically (but implicitly)
typed, so no run-time overhead is involved, and all type errors are
detected at compile-time.

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop




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 reversed, because of the drop in speed you got when
using generics.


Ah! So that is where those ifdefs in classes come from :) I always
wondered...


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.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 is impossible to explicitly declare tuple type,
or store a tuple in a variable.


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.)



2.2) Tuple construction: Tuple may be constructed by listing its
elements in as a semicolon-separated list in parenthesis:
   (a; b; c). Also, any value of record or array type can be converted
to a tuple by using built-in pseudo-function Tuple
   (or other some name, perhaps even a special character like ~ or @@).
   Semicolon is chosen to underline similarity with the record
constants -- but perhaps comma is better.
   Alternatively, a square brackets may be used since they already
represent similar semantics for array of const parameters.


As I said in my other mail I'm still not sure whether (...) is a good 
idea, because there can be code like i := (42) (it's not forbidden and 
thus it needs to be allowed with such an extension as well). 
Nevertheless I'd prefer , as a seperator.


Also I'd definitely prefer NOT to use special characters. Instead I'd 
prefer the use of an instrinsic like Tuple (though - together with my 
declaration proposal - one needs to pay special attention to the 
difference of Tuple(...) and tuple of (...) in the parser)



2.3) Tuple assignment. Tuple may be assigned to a record, provided
field types match. Most important, tuples may be used in
deconstructing assignment by listing variables in the same syntax on
the left side of assignment:
   (a; b) := (x; y);
If the left side contains less variables then the tuple has values,
extra values are ignored.
If the right side contains more variables, it is an error.


I don't know whether we should use this value ignoring. Maybe always 
an error if the count differs is better... (and in the case of a Tuple 
returned by the Tuple intrinsic we'd also need a new RunError and 
Exception type)



2.4) Tuples as procedure arguments. Tuple may be passed to a procedure
or function.
In this case, deconstructing assignment is performed from the tuple to
the actual arguments,
as if they were listed on the left side of assignment in the previous point.
Also, a tuple may be present inside square brackets representing
array of const argument.
In this case, it works as if tuple elements were listed instead.



Together with my declaration proposal this is a bad idea. So no 
deconstructive assignments on procedure calls. Things like this can be 
allowed though:


=== code begin ===

type
  TTestTuple = (Integer, String);

procedure Test(aArg1: String; aArg2: TTestTuple; aArg3: Integer);

// somewhere else
Test('Foobar', (42, s), i);

=== code end ===


2.5) for-in loop accepts a list of variables after for keyword. In
this case, it tries to convert the Current value to a tuple and
perform tuple assignment.


It should not only be a list of variables, but a tuple deconstructor:

=== code begin ===

for (key, data) in SomeContainer do
  ...

=== code end ===

The enumerator then of course needs to return a fitting tuple type.

This way one can keep the current enumerators (maybe except build in 
ones): they just don't return a tuple type, but a scalar and thus 
you'd continue to write


=== code begin ===

for data in SomeContainer do
  ...

=== code end ===



With this proposal, following benefits are gained:

1) Group assignment:
(x; y; z) := (0; 0; 0);
(a; b) := (b; a);
(first; second) := Tuple(SomeFunctionReturningArray());



Agreed.


2) Record literals without constructor functions:
   ARectangle.TopLeft := (100; 200);



I don't know whether this should be possible without an approbiate 
intrinsic (the inverse of Tuple), but I'm open here...



3) Formatting complex values:
   s := Format('%d-%d', [Tuple(CenterPoint(ARectangle))]);


Format would need to be adjusted to support Tuple types, but ok...



4) Collecting default values for procedures:
In some library:
procedure WithManyParams(A, B, C, D, E, F: Integer);
In user code:
var
   p: record A, B, C, D, E, F: Integer; end;

p := (default; values; for; params);
...
p.E := 5;
WithManyParams(Tuple(p));


As said above this is a no in my opinion.



5) Finally, for-in:
for (v; i) in a do ...
Compiler code for built-in types mostly the same as for-in-index --
syntax difference only.
User-defined iterators may return records with fields (value, key).
In the case of
for v in a
v may now be either a record or just a value, depending on the type.


Basically agreed.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org

Re: [fpc-devel] for-in-index loop


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 less explicit for sure.


Personally, I think the tuple approach proposal is more general, and
therefor better.

Once more, I do not think that language extensions are bad. I judge them
on a case by case basis.

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 original poster's
problem, you will not hear me protesting, it will have been well worth
the energy I put in this discussion.


Then let's better concentrate our energy to implementing tuples in a 
good way and (more or less) everyone will be happy :D


I'd suggest to start a new thread for that if we want to discuss 
proposals for syntax, semantics, corner cases, etc.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop




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.

So if someone were to introduce that to solve the original poster's problem,
you will not hear me protesting, it will have been well worth the energy I
put in this discussion.



There are two reasons I proposed latter instead of former:
1) I think using keyword is more explicit and readable
2) I thought that smaller feature is easier to argue for than a large one --
 apparently, I was mistaken on that :)


Well, a tuple is simply a new fundamental type.

Just like generics, BTW.


So, amended for-in-index proposal:
1) The syntax is
for value, key in container do ...
2) The enumerator interface is extended with optional
property CurrentWithKey: TValueKey;
where TValueKey must be a record with two fields.


I don't think we need a record.

Lets first see about how to implement general tuple values before you start 
restricting it. I see Sven is already working on some ideas.


It may be more work up front, but it will be a more fundamental solution.

To be clear, the for in index syntax with 'index' keyword will not 
be recuperated.


No temporary workarounds/hacks. Decent solutions.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop




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) extension for for-in loop will
not make it less explicit for sure.


Personally, I think the tuple approach proposal is more general, and
therefor better.

Once more, I do not think that language extensions are bad. I judge them
on a case by case basis.

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 original poster's
problem, you will not hear me protesting, it will have been well worth
the energy I put in this discussion.


Then let's better concentrate our energy to implementing tuples in a good way 
and (more or less) everyone will be happy :D


100% agreed.

The way may be hobbly, but at least we go forward...

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: Anonymous procedures (Was: Re: [fpc-devel] for-in-index loop)

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


Of course, the Delphi-compatible implementation is a basis --
I did not even mention it, because I thought it is obvious.
(Although I would still like to devise some solution for using
closures for events --
IDE does not recognize them seems quite a weak obstacle to me).

My proposals were for syntax extensions to eliminate the ugliness of
procedure-inside-extression construct.

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: Anonymous procedures (Was: Re: [fpc-devel] for-in-index loop)


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:
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/anonymousmethods_xml.html



Of course, the Delphi-compatible implementation is a basis --
I did not even mention it, because I thought it is obvious.
(Although I would still like to devise some solution for using
closures for events --
IDE does not recognize them seems quite a weak obstacle to me).



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.



My proposals were for syntax extensions to eliminate the ugliness of
procedure-inside-extression construct.


Too which I principially agree (the elimination of the ugliness, not 
necesserily the syntax proposed by Alexander)


Regards,
Sven

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: Anonymous procedures (Was: Re: [fpc-devel] for-in-index loop)

2013-01-26 Thread kyan

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 have one:

 http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/anonymousmethods_xml.html


 Of course, the Delphi-compatible implementation is a basis --
 I did not even mention it, because I thought it is obvious.
 (Although I would still like to devise some solution for using
 closures for events --
 IDE does not recognize them seems quite a weak obstacle to me).


 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 this:
http://blog.barrkel.com/2010/01/using-anonymous-methods-in-method.html
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-26 Thread Hans-Peter Diettrich


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 for array of Vaiant and array of const -- they are very different
from the tuples proposal.
Note that tuples proposal is carefully constructed in such a way that
tuples are statically (but implicitly)
typed, so no run-time overhead is involved, and all type errors are
detected at compile-time.


I doubt that this is possible in OPL without much additional (type, 
name) information in source code. Consider how many number types exist, 
so that [1] can be a 1-tuple of almost any numeric type. Depending on 
what exact type the compiler chooses, the type may be too big or too 
small for subsequent assignments of other values, or to records. A 
practical implementation IMO will ressemble a record definition with 
explicit types added to every element. Otherwise array of const could 
be used, with included type information, and (automatic) type conversion 
when a tuple is used as a parameter list or operand.


The use as an argument list replacement will hardly match the signature 
of the subroutine, which expects exact types, modifiers (const/var) and 
calling convention (register/stack usage).


I don't see how tuples can be used without a new variable type. Without 
such an container the assignment of one tuple to another one will have 
no useful effect, because the result is lost.


Can you give more practical examples on your idea of using tuples in OPL?

I only could find an obvious use in record constructors, where the 
target record provides the tuple type as in

  ARectangle.TopLeft := (100; 200);
or better
  ARectangle.TopLeft := [100, 200];
This would be nice, indeed, but hardly worth to introduce tuples for 
only this purpose.


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: Anonymous procedures (Was: Re: [fpc-devel] for-in-index loop)

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 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 language level -- for example, make
TMethod managed type
and fully unify procedure, procedure of object and reference to procedure.
This will of course incur some performance cost, but since event
variables are in 99% of cases
created and destroyed together with components, and components are
quite heavy anyway,
I suspect the cost will be negligible, especially with the help of
clever enough optimizer.
Further, after that, since all events will become object instances anyway,
C#-style event stacking may become feasible, replacing rather cumbersome
hand-made chaining or AddHandler/RemoveHandler interfaces.

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

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.

 (x, y, z) := (0, 0, 0); // OK
 (x, y, z) := Tuple(0);  // OK
 (x, y, z) := (0, 0);// Not OK
 (x, y, z) := Tuple(0, 0);   // Not OK

 So if I understand things correctly, brackets [] are used where the number
 of contained elements is indeterminate (sets, multidimensional array
 indices, arrays of const) and parentheses where it's determinate (tuples,
 record initialisation etc.).


Note that in my proposal I suggested to allow array deconstruction and
ignoring extra elements on the right side,
so mass initialization may be implemnted by something like this:
const
  ZEROES: array [1..10] of Integer = (0, 0, ..., 0);
...
(x, y, z) := Tuple(ZEROES);
alternatively:
function Repeat(AValue: Integer; ACount: Integer = 10): TIndegerDynArray;
...
(x, y, z) := Tuple(Repeat(777));

Anyway, I do not think mass-assignment of the same value is
particularly important
compared to the general case of mass-assignment of arbitrary values.

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: Anonymous procedures (Was: Re: [fpc-devel] for-in-index loop)


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, ' = ', aData.ClassName));



I think that they are not optimal in the proposed form.
Note that the longest part of the expression is actually a restatement
of the Iterate parameter type.
I propose to allow omitting that:

map.Iterate(lambda begin
Writeln(aKey, ' = ', aData.ClassName);
end;)

That is, basically, lambda means use procedure definition from the
parameter type.


I have already thought about this as well, but this is simply not how Pascal
(and especially the compiler) works. In Pascal the result of an expression
is (at first) independantly of the result it is assigned to. For example:

double1 := 1.0/2.0;

here the expression on the right side will be evaluated with the smallest
possible precision that does not cause data loss (let's assume for now that
1.0, 2.0 and 0.5 all can be represented by a Single) and only in the
assignment the result is converted to a Double.



Also there's the problem of overloaded procedures. Let's assume we have

type
   TProc1 = reference of procedure(aArg: Integer);
   TProc2 = reference of procedure(aArg: String);

procedure SomeProc(aArg: TProc1);
procedure SomeProc(aArg: TProc2);

SomeProc(lambda as Writeln(aArg));

Which SomeProc to choose? Even if the lamda's code could derive the argument
types directly (which must not be the case as you can see in the example, as
Writeln can take an Integer as well as a String) you'd still need to find
the correct procedure.


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,
and overload resolution will work.


While the compiler would be satisfied by this, this nevertheless leaves 
the problem that we (as in the user of the language) don't really see 
where the aArg comes from...


I can already imagine many questions like the following appearing on the 
mailing list:


=== quote begin ===

type
  TMyProc = reference to function(aArg: Integer): String;

procedure SomeProc(aArg: Integer);
begin
  SomeProcTakingTMyProc(lambda TMyProc as IntToStr(aArg));
end;

Why doesn't the lambda expression return the value that's passed to 
SomeProc, but something completely different?!


=== quote end ===




Also the parameter names MUST be declared somewhere. This is Pascal. There
can't be a symbol name appearing suddenly in the middle of the code.

They are declared in the definition of TProc1 type.
This is similar to records -- fields are declared in type definition.


These three points are why I proposed my example as is: we need somehow the
signature of the lambda. Maybe lambda(aArg: Integer) as Writeln(aArg)
would be sufficient already (or lambda(aArg: Integer): String as
IntToStr(aArg) for a function).

This just replaces procedure with lambda, so nothing is gained.
The possibility to omit duplicated parameter lists is, in my opinion,
quite important
for this whole feature to be useful.



Yes, I'm aware of that...

Maybe the idea that I presented in the mail in the for-in-index thread:

lambda TProc(aArg) as ...

TProc is used to bind the correct type and the names in the parentheses 
are mapped to the arguments of TProc.



Independently, I propose a general shorthand for functions containing
a single expression
(and perhaps for procedures containing a single statement, but I am
less certain here):

function f(a, b: Integer): Integer;
begin Result := a + b; end;
=
function f(a, b: Integer): Integer as a + b;


I don't know whether I'd want to extend this to single line
functions/procedures. This is where the language becomes less clear again.


While I do not feel too strongly about this, consider these arguments:
1) Orthogonality is one of the important first principles of language design,
   and of Pascal design in particular -- every feature should work in
combination with every other.
   So it is bad to allow shortcut syntax in procedures used as
parameters, and disallow otherwise.
2) With the introduction of anonymous functions,
function f(a, b: Integer): Integer;
can be rewritten as
f := function (a, b: Integer): Integer;
which strengthens point (1) above.
3) Single-statement procedures/functions are moderately common -- including
operator overloads, simple getters/setters, various utilities, nested
helper procedures.
Quite a few times, I resented the fact that extracting a single-line
nested procedure,
while clearing code at the point of calling, inconveniently increases
total line count by five(!) lines,
thus significantly offsetting the readability gains.
With shortened syntax, line count will be incremented only by two,
which is much better.



Ok, if you come with orthogonality...

Re: Anonymous procedures (Was: Re: [fpc-devel] for-in-index loop)

2013-01-26 Thread Marco van de Voort

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 language level -- for example, make
 TMethod managed type
 and fully unify procedure, procedure of object and reference to 
 procedure.
 This will of course incur some performance cost, but since event
 variables are in 99% of cases

I sincerely hope you are kidding here. Do not slow existing constructs.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: Anonymous procedures (Was: Re: [fpc-devel] for-in-index loop)

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 the parameter type,
 and overload resolution will work.

 While the compiler would be satisfied by this, this nevertheless leaves the
 problem that we (as in the user of the language) don't really see where
 the aArg comes from...

 I can already imagine many questions like the following appearing on the
 mailing list:

 === quote begin ===

 type
   TMyProc = reference to function(aArg: Integer): String;

 procedure SomeProc(aArg: Integer);
 begin
   SomeProcTakingTMyProc(lambda TMyProc as IntToStr(aArg));
 end;

 Why doesn't the lambda expression return the value that's passed to
 SomeProc, but something completely different?!

 === quote end ===

This is quite similar to using with statement -- yes, name clashes
are possible.
Perhaps they should be disallowed, like currently it is impossible to
declare local variable
overriding class field (except in Delphi mode).
In this case, user will have to revert to full syntax.

 Maybe the idea that I presented in the mail in the for-in-index thread:

 lambda TProc(aArg) as ...

 TProc is used to bind the correct type and the names in the parentheses are
 mapped to the arguments of TProc.

Well, this would be yet another step backwards.
The break-even point where the gain is not enough to justify the
feature would be quite near.
I'd prefer the previous variant -- with additional safety as described above.

 Just one point to ensure we understand this the same: if we use the
 abbreviated syntax (as STMT/EXPR) then no variable/type/constant
 declarations are possible.

Of course, that's the point of the shorthand.

 What still bothers me a bit is the handling of result values... if we
 require the code after the AS to be an EXPR we'd need to implicitely assign
 the result value. What does now happen if the lambda's type does require a
 return value, but we don't provide one? What the otherway round?

I suggest the following:
Shortcut for functions *require* expression as body,
since the only correct single statement would be assignment to Result
(or call to Exit with an argument).
Shortcut for procedures *require* a statement.
Of course, the statement may be a function call, but that does not
matter for procedure.

 === example begin ===

 type
   TProc = reference to procedure;
   TIntFunc = reference to function;

 x := lambda TProc as fMyMemo.Lines.Add('FooBar'); // Add returns Integer
ok
 y := lambda TIntFunc as Writeln('Foobar');
Syntax error: expression expected

 But in this case, perhaps you are right, how about (taking into
 account the discussion of lambda above):

 sum := a.Reduce with lambda TAdderFunc as a + b;
 or without type helpers:
 sum := Reduce with a, lambda TAdderFunc as a + b;

 While I still don't know why you'd want to replace parenthesis I would
 definitely prefer this syntax over any : you can throw at me ^^

This is mostly to avoid JavaScript-style mixed closing brackets in nested calls:

a.forEach(function (aelem) {
  aelem.forEach(function (v) {
doSomething(v);
  })
});

with the no-parenthisis extension, the Pascal equivalent may be
(suppose the actual code is long, so as shortcut does not apply):

a.forEach with lambda TAElemProc begin
  AElem.forEach with lambda TIntegerProc begin
doSomething(v);
  end;
end;

without the extension, the Pascal equivalent may be:

a.forEach(lambda TAElemProc begin
  AElem.forEach(lambda TIntegerProc begin
doSomething(v);
  end);
end);
--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop




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
programmer) /to improve good open project. Work will not have any good
value for me if results of work will not have any good value for other
people.


That's good that you have resources and motivation. The question is where to 
apply them.



I understand why you don't want to support bad features. But I don't
understand why reasonable extension of existing feature (which will not
break compatibility and which exists in other languages) is bad ? :)


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 developers :)


Paul,

Sorry, but I most certainly will do this.

It is not because it is technically possible that it must be allowed or done.
The use case presented is SO MARGINAL that it does NOT justify another language 
feature.

less is more:

WITH EACH ADDITIONAL FEATURE WE ARE BUTCHERING PASCAL MORE AND MORE.

Borland/Inprise/Embarcadero is doing bad enough, we do not need to add it.

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'.

Well:
It is simply no longer true. Java, Javascript and C have become more easy.

Simply because we are afraid to say 'No sorry, you are on the wrong path'.

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: Well, get started !
Both should be perfectly within grasp of a student.
If he has students, let them work on that.

If they must develop a 'language extension' for practice, using FPC: great.
But that does not mean it should be added to FPC's distribution.

Pascal needs more useful libraries. More platforms.
But definitely *not* even more shady language features.

Language features can of course be added, but PLEASE with a broader use case.

Once more: simple is beautiful.

Free pascal becomes less so with each of these features.

Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

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 current item is returned when you call Next or Previous on the
iterator. You use HasNext and HasPrevious in the loop. As the article
describes, my Iterator implementation is based on the Java-style where
the pointer in the list sits between items - there is a graph of that in
the article too.

 they also do not have concept of an index, and hence are not relevant
 in the context of this discussion.

No need for an index value because Next and Previous returns what you
need. Also the one Iterator I implemented can take a regular expression
(regex), thus you can iterator a list but filtered results are returned.
The article shows this somewhere near the end. So the traditional
index value doesn't or can't apply, because it can skip many or all
items in the list.


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop




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 course you do not, this is why I said please :)
However, it is impossible to have a meaningful discussion without such
an example, so could you please indulge me?


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 because it can be done, that it must be done.

The point is that with every 'feature' added, the language becomes 
more and more ugly.


My main worry is that Object Pascal, which used to be a beautiful, 
easy to learn language is becoming a horrible, complicated, monster of a langauge.


In large part due to Borland/Inprise/Embarcadero going downhill after D7.

This proposal adds once more to the uglyness and complication.

As for the feature being present in some other languages, 
I stand corrected; Next time I will be more careful in my statements.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Martin Schreiber

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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop




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. ;-)


Hear, hear: Martin and I agree.

After so many years. It brings a tear to my eye ;-)

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 because it can be done, that it must be done.

 The point is that with every 'feature' added, the language becomes
 more and more ugly.

 My main worry is that Object Pascal, which used to be a beautiful,
 easy to learn language is becoming a horrible, complicated, monster of a
 langauge.

In general: +1

Even the common syntax highlighters have trouble. I don't know if Delphi's
syntax highlighter understand their language fully.

But I must admit the for-in-loop makes code easier to read. I see it with
beginners and people coming from other languages. They instantly understand it
and use it.
Of course this is only about the loop itself, not how an enumerator is
created/declared. That is difficult to understand.


 In large part due to Borland/Inprise/Embarcadero going downhill after D7.

 This proposal adds once more to the uglyness and complication.

 As for the feature being present in some other languages,
 I stand corrected; Next time I will be more careful in my statements.

Please keep up the good work and question any new feature.


Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop




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 'missing features'.

The point is: it is not because it can be done, that it must be done.

The point is that with every 'feature' added, the language becomes
more and more ugly.

My main worry is that Object Pascal, which used to be a beautiful,
easy to learn language is becoming a horrible, complicated, monster of a
langauge.


In general: +1

Even the common syntax highlighters have trouble. I don't know if Delphi's
syntax highlighter understand their language fully.


Bah. The Delphi IDE does not even understand include files.



But I must admit the for-in-loop makes code easier to read. I see it with
beginners and people coming from other languages. They instantly understand it
and use it.


I believe that. In it's simple form, it is indeed easy to understand and use.


Of course this is only about the loop itself, not how an enumerator is
created/declared. That is difficult to understand.


I agree. What is more, the way Delphi introduced it is simply braindead.

In this case, I think that the FPC alternative (operator enumerator) is more 
easy and more pascal-ish.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 
structures which store pairs of key and value associated with key.


Is this (among other purposes) supposed to allow for working with UTF-8 
strings in a per-character-index manner ?


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Marco van de Voort

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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Marco van de Voort

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 gtree discussion,
and all FPC generics are in its own incompatible syntax.

This makes it hard for me to contribute anything.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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
  http://wiki.freepascal.org/for-in_loop#Proposed_extensions . From my point
  of view it's essential part of iterators. E specially for data structures
  which store pairs of key and value associated with key.

The above UTF8 example misses some points. Often you need the index and often
you need the byte position.
This can be remedied with an enumerator using a record:

type
  TUTF8Enummy = record
c: UTF8Char;
ByteIndex: SizeInt;
UTF8Index: SizeInt;
  end;

  TUTF8StringEnumerator = class
  ...
  public
constructor Create(const A: UTF8String);
function Current: TUTF8Enummy;
function MoveNext: Boolean;
  end;
  ...

var
  s: UTF8String;
  ch: UTF8Char;
begin
  for ch in s do
Writeln(ch.UTF8Index, ': ', ch.c,' at byte ',ch.ByteIndex);
end.

The compiler already supports such constructs.
It seems this is even more powerful and useful than the proposed 'index'
extension.

Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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: 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. E specially for data structures
   which store pairs of key and value associated with key.

 The above UTF8 example misses some points. Often you need the index and often
 you need the byte position.
 This can be remedied with an enumerator using a record:

 type
   TUTF8Enummy = record
 c: UTF8Char;
 ByteIndex: SizeInt;
 UTF8Index: SizeInt;
   end;

   TUTF8StringEnumerator = class
 ...
   public
 constructor Create(const A: UTF8String);
 function Current: TUTF8Enummy;
 function MoveNext: Boolean;
   end;
   ...

 var
 s: UTF8String;
ch: TUTF8Enummy;
 begin
   for ch in s do
 Writeln(ch.UTF8Index, ': ', ch.c,' at byte ',ch.ByteIndex);
 end.

 The compiler already supports such constructs.
 It seems this is even more powerful and useful than the proposed 'index'
 extension.


Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 
character needs quite a lot of CPU time, so it would be nice to have a 
kind of enumerator that (e.g.) in a smart way remembers a set of 
(Byte_Position / printable_Character_position) pairs helping to quickly 
find the n'th printable character.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop




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 independently the 15 th printable 
character needs quite a lot of CPU time, so it would be nice to have a kind 
of enumerator that (e.g.) in a smart way remembers a set of (Byte_Position 
/ printable_Character_position) pairs helping to quickly find the n'th 
printable character.


Pchar ?

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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

for I = 1 to 10 do begin
  n = Integer (random(10));
  c = myString[n];
end;

Is rather fast with ANSI coded Strings.

When myString is coded in utf-8, it obviously provides silly code byte 
instead of printable characters, and replacing the term myString[n] by a 
straight forward  function searching for the n'th printable character 
will be very slow.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 string

Do you mean codepoint?
Printable depends on ligatures and other things.


 Finding the 10 th and then independently the 15 th printable
 character needs quite a lot of CPU time

In UTF8, UTF16 and UTF32 it takes 5 steps.

, so it would be nice to have a
 kind of enumerator that (e.g.) in a smart way remembers a set of
 (Byte_Position / printable_Character_position) pairs helping to quickly
 find the n'th printable character.

There are plenty of functions for this. You can wrap them into enumerators as
demonstrated.

Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop




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 for a given n you need to scan all bytes  m.


I know that too.


Thus a loop such as

for I = 1 to 10 do begin
 n = Integer (random(10));
 c = myString[n];
end;

Is rather fast with ANSI coded Strings.


Yes, but this is random access in a string.

Enumerators will not help you with random access, only with sequential access.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 (m=n).

 To find m for a given n you need to scan all bytes  m.

 Thus a loop such as

 for I = 1 to 10 do begin
 n = Integer (random(10));
 c = myString[n];
 end;

 Is rather fast with ANSI coded Strings.

Same silly loop in UTF8:

// find random characters in myString
for I := 1 to 10 do begin
  n := Integer (random(10));
  cp := UTF8FindNearestCharStart(PChar(myString),length(myString),n);
end;


 When myString is coded in utf-8, it obviously provides silly code byte
 instead of printable characters, and replacing the term myString[n] by a
 straight forward function searching for the n'th printable character
 will be very slow.

Maybe real world examples would be better to prove a point.

Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Daniël Mantione




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 you need to scan all bytes  m.

Thus a loop such as

for I = 1 to 10 do begin
 n = Integer (random(10));
 c = myString[n];
end;

Is rather fast with ANSI coded Strings.

When myString is coded in utf-8, it obviously provides silly code byte 
instead of printable characters, and replacing the term myString[n] by a 
straight forward  function searching for the n'th printable character will be 
very slow.


Yes, it is a known fact that this is a weakness of UTF-8. Consider 
transforming the string to UTF-16, UTF-32 or even an internal 
datastructure before doing the random access.


Random access inside UTF-8 is an algorithmic time complexity issue. A 
language extension can only be a band-aid for that.


Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 about plain enumerators.


Obviously he wants to have or provide some compiler magic support for 
non-standard indexing.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Marco van de Voort

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.
 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop




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 said 
that the OP did not really meant to talk about plain enumerators.


I think you have me confused with someone else :-)

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 here at any length, resulting in the 
knowledge that this also does not help in all cases (as all Unicode 
variants allow for extended codes).


Delphi XE and mse use UTF-16 by default as a (in most cases appropriate) 
compromise. I suppose, FPC and Lazarus will follow at some point in 
time, making  these discussions less stringent.


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 implementations.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop


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 implementation of the indexer class.

Ligatures depend on the font. This is outside the scope of the RTL and
especially any compiler magic. A rendering library might implement such an
enumerator.


  Finding the 10 th and then independently the 15 th printable
  character needs quite a lot of CPU time
  In UTF8, UTF16 and UTF32 it takes 5 steps.
 What do you mean by steps ?

I meant if you have the 10th codepoint you can find the 15th codepoint
in 5 steps.
With current compiler magic you can write an enumerator for this task.


  There are plenty of functions for this. You can wrap them into
  enumerators as demonstrated.

 In fact I easily could do my own implementation of the functionality if
 I would have the need for it.

 The question is whether it would make sens to provide a fast
 implementation of such a class in the RTL and offer some compiler magic
 to make it easily usable (e.g. for beginners) and compatible with
 possible future string types to prevent any porting effort of user code.

Please keep in mind that working with strings and working with Unicode are
different things.
The old simplicity of 8-bit codepages is a thing of the past. It was an
optimization that worked for a few small regions. Programmers must understand
that printed characters can not be represented by single numbers.

Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread dev . dliw

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 would be a great mistake to bloat / fragment Pascal with 
redundant features and go exactly the other way round.

IHMO even Delphi does too much of a 'good' thing in evolving the language
- and the best example how NOT to do it - is Perl, indeed.

Btw. from the users point of view - there are more urgent things to do.
[NOTE that's NOT a hidden complaint/hint!].
d.l.i.w

P.S.:
I got to know Pascal with Turbo Pascal (in fact I'm younger than you might 
think :) )...
... but - honestly - I still don't understand why Borland introduced classes 
when there are objects, what the heck are advanced records for... etc. :)
Ok, many features are really useful: generics, properties...
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

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 iterating the UTF-8
string, so index access wasn't needed.


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

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

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread vrt277


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 developers :)

Let's look how suggested feature makes compiler worse. Some answers I 
already know, some needs to be clarified:


1. Does it adds new (semi-)reserved words? No, index is already a 
semi-reserved word which is used for property declaration. So scanner 
will not be changed.


2. Does it influence other features than for-in loop? As I see, other 
parts of compiler will not be changed.


3. Will it add much code which is needs to be supported? I don't know 
but expect it will add not much. Vasiliy, can you put your patch 
somewhere to look at overall compiler change?


4. Jonas, can you tell about for-in loop for objective-pascal dialect? 
I know it implementation depends on some Objective-C classes. Do they 
support current index/key return? Do you against 'index' extension for 
ObjP dialect and in general?


Best regards,
Paul Ishenin

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Hi Paul,

1. scanner will not be changed.
2. It will not influence other features than for-in loop.
3. Link located at end of message. You also can visit 
https://github.com/vkevroletin/freepascal/compare/master...key-value-iterator 
in your browser.
4. - (yes there is difficulty with Objective-C, it skipped in my pilot 
implementation)


P.S.
patch: https://docs.google.com/file/d/0B36IYx_6MNY6bzY2Sm9Hc3o5QlE/edit
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

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 implementations.


I think you got programming confused with a magic wand.  ;-)


G.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread vrt277


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 what mailing list is better ? In mailing list new 
user will not see even things that was started. I also dislike poorly 
maintained wiki and poorly maintained software and poorly maintained 
anything.



We do not need more language features.
Your point of view is clear and immutable. I guess main reason for you 
to include for-in loop in language was delphi.


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 translate Pascal to Javascript is should be 
interesting even from academic point of view.
As for everyday programming in IT company then I have my own experience 
and will decide what is useful for me myself :)


You have good wishlist. May be it would be better to store it not in 
mailing list.


Vasiliy Kevroletin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop




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 actually finished.


Probably you think what mailing list is better ? In mailing list new user 
will not see even things that was started. I also dislike poorly maintained 
wiki and poorly maintained software and poorly maintained anything.


I am glad we agree.

I do not think that a mailing list is better for keeping lists.
I use it for communication only.


We do not need more language features.
Your point of view is clear and immutable. I guess main reason for you to 
include for-in loop in language was delphi.


It was.

I want to stress that I am not against new language features.

But at the same time I do not think that all possible use cases 
must be translated to new language features.


The fight against language bloat is a difficult balance.

For in is there. It can be used in many wonderful ways. 
As such I do not see the need for an extension.


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 translate Pascal to Javascript is should be 
interesting even from academic point of view.


Well:
There are even different possible approaches. Last year a google summer of code
proposal was made to achieve this in FPC. I was quite surprised to see that it 
was totally different from what I myself had in mind.


As for everyday programming in IT company then I have my own experience and 
will decide what is useful for me myself :)


Of course; I only presented what is on my personal wishlist...

You have good wishlist. May be it would be better to store it not in mailing 
list.


I can store the list in the WIKI if this is desirable. 
Although I am afraid it will get lost in the depths of Google anyway ;-)


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread 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. He said maybe he'd look after fcl-stl. The
 silence since was deafening.
for-in-index extension was actually planned by me as a prerequisite
for fcl-stl work.
I did some experiments with the current implementation, even discussed
it at a conference
related to teaching of algorithmic programming to children.
As I have already explained, main competition in this area now comes
from Python and
other dynamic languages. While discussing container access in Pascal vs Python,
lack of for-in-index was brought up by attendees as one of Pascal's
weaknesses.

 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 rights)
should perform the addition.

 Both should be perfectly within grasp of a student.
 If he has students, let them work on that.
Unfortunately there are specific requirements for this type of student work
(it is approximately equivalent to bachelor's thesis).
A single large new feature is much better suited to it then
polishing the library, with many small refactorings and improvements.
Note that for Vasily, for-in-index if not actually this large feature,
it was chosen by me as a relatively minor and simple feature to introduce him
to the code base and the community.
I am sorry that the community turned out not quite welcoming.

 Pascal needs more useful libraries.
It is important to note that default libraries ARE part of the language,
and from the user's POV language vs library distinction is an irrelevant detail.
What is important is a clear, concise and easy-to-remember syntax.

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.

In your proposal, he should write (suppose GIter is a unit
implementing the generic array iterator):
uses
  GIter;
type
  TArrayIntIterator = specialize TArrayIteratorInteger;
  i: TArrayIntIterator.TElem;
begin
  for i in TArrayIntIterator.Create(a) do
Writeln(i.Index + Low(a), ' ', i.Value);
end.

Now my point is that second variant is harder to learn and understand
then the first one,
regardless of the fact that is uses simpler language.
And yes, I have code for the second example in my working copy of
improved fcl-stl.

--
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Sven Barth


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 translate Pascal to Javascript is should be 
interesting even from academic point of view.


Well:
There are even different possible approaches. Last year a google 
summer of code
proposal was made to achieve this in FPC. I was quite surprised to see 
that it was totally different from what I myself had in mind.



Do you have link for this?

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Florian Klämpfl

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. He said maybe he'd look after fcl-stl. The
 silence since was deafening.
 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 did some experiments with the current implementation, even discussed
 it at a conference
 related to teaching of algorithmic programming to children.
 As I have already explained, main competition in this area now comes
 from Python and
 other dynamic languages. While discussing container access in Pascal vs 
 Python,
 lack of for-in-index was brought up by attendees as one of Pascal's
 weaknesses.

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. Depending on the iterated container, iterators might
be still valid even if the container changes.

 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:=low(a) to high(a) do
  writeln(i,' ',a[i]);

Works afaik since TP 6.0.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Daniël Mantione




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.


Well... I fail to see the improvement over old fashioned:

for i:=low(a) to high(a) do
  writeln(i,' ',a[i]);

Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Sven Barth


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 rights)
should perform the addition.
Do you have a link to the message? It could have been gotten lost in the 
usual mailing list traffic...

I am sorry that the community turned out not quite welcoming.
You should not generalize here. There were devs (e.g. Paul) and also 
users who didn't object. Others did indeed object. But we're humans 
after all... not every one has the same opinion. Take myself: I consider 
myself neutral in this topic. I'm neither really pro nor against this 
feature.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Hans-Peter Diettrich


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 needed. Or use what 
the RTL provides for such purpose...


Finding the 10 th and then independently the 15 th printable 
character needs quite a lot of CPU time, so it would be nice to have a 
kind of enumerator that (e.g.) in a smart way remembers a set of 
(Byte_Position / printable_Character_position) pairs helping to quickly 
find the n'th printable character.


I think that you are abusing strings for demonstration purposes only. I 
bet that you really wanted the 11th character, because you made an 
mistake while counting characters, or that you missed to organize your 
super-long string into smaller pieces (lines, columns...).


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Daniël Mantione




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]);

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 induction is such a well documented 
optimization that implementation of that optimization (could be a nice job 
for a student) is by far preferable over mutilating the language.



2) If a is a function of another complex expression returning an
array, then for-in may be much more efficient and compact


Again true, but again easy to avoid: temp variable, with statement, common 
subexpression elimination. Again these are all preferable over mutilating 
the language.



3) If a is an associative array (so i is a String), then the
traditional form of loop is not even possible.


Disagree. You need to define a mapping between an ordinal type and the 
index type. This is always possible (otherwise for-in would be impossible 
to implement).



4) If there is no uniform method for iterating over containers, then
each container will define its own method,
 with the end result that the language will be *more* complex for the
user, who will have to remember all these methods.


This I consider a valid argument, and it affects the fundament of what a 
for loop is. A for loop iterates over the keys only, while the values are 
retrieved by [] syntax. This is perfectly possible even for non-numeric 
keys as we have properties that allow you to do a['elephant'].


The for-in syntax violates this fundamental property by returning values, 
which means there is a lack of a key. The fundamentalistic view then says 
we should not have for-in in Pascal, because it changes the fundamental 
property of a for-loop.


For pragmantic reasons the for-in syntax got supported. However, when 
using it you discover the lack of keys. So you want to repair something 
that's already broken by design.


The question becomes, which is worse? Further mutilation? Or stick to the 
basics?


Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Sven Barth


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.

In your proposal, he should write (suppose GIter is a unit
implementing the generic array iterator):
uses
   GIter;
type
   TArrayIntIterator = specialize TArrayIteratorInteger;
   i: TArrayIntIterator.TElem;
begin
   for i in TArrayIntIterator.Create(a) do
 Writeln(i.Index + Low(a), ' ', i.Value);
end.


One could also do an alternative (though currently not with arrays, but 
with type helper support even that would be possible...):


=== code begin ===

type
  // let's assume we extend fgl.TFPGMap a bit
  TFPGMapKey, Data = class
  public type
TIteratorProc = procedure(const aKey: Key; const aValue: Data);
  public
procedure Iterate(aProc: TIteratorProc);
  end;

// skipping the implementation of TFPGMap.Iterate...

// somewhere else

  procedure Iterator(const aKey: String; const aValue: TObject);
  begin
Writeln(aKey, ' = ', aValue.ClassName);
  end;

type
  TFPGMapStringTObject = specialize TFPGMapString, TObject;
var
  map: TFPGMapStringTObject;
begin
  // set up map

  map.Iterate(@Iterator);
end;

=== code end ===

With support for anonymous functions (and changing TIteratorProc to 
reference to procedure(...)) it even becomes:


=== code begin ===

begin
  map.Iterate(procedure(const aKey: String; const aValue: TObject)
begin
  Writeln(aKey, ' = ', aValue.ClassName);
end;
  );

end;

=== code end ===

And for a given array type and type helper support you can do the following:

=== code begin ===

var
  t: TLongIntArray; // there exists a helper for this type that 
implements a Iterate function

begin
  // set up t
  t.Iterate(@Iterator);
  // or
  t.Iterate(procedure(const aIndex, aData: LongInt)
begin
  Writeln(aIndex, ' = ', aData);
end;
  );
end;

=== code end ===

In all cases the iterate function would iterate the container type 
with a fitting algorithm and just call the given function with the 
necessary data. This is in my opinion a rather flexible way of dealing 
with iteration (by adding additional arguments you could for example 
influence the iteration direction).


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Florian Klämpfl

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 princilpes you are talking about,

The theory of iterators.

 but accessing the key of the current element is required quite often
 and provided by iterator implementations in many programming languages

The approach to do so is to use a random access iterator in this case.

 (except for Java, as discussed above).
 I have already provided examples.

Where? Concrete code of a serious language! Not some oh, yes, this
language has it and that as well
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop




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 a index i do
 Writeln(i, ' ', v);
end.

In your proposal, he should write (suppose GIter is a unit
implementing the generic array iterator):
uses
   GIter;
type
   TArrayIntIterator = specialize TArrayIteratorInteger;
   i: TArrayIntIterator.TElem;
begin
   for i in TArrayIntIterator.Create(a) do
 Writeln(i.Index + Low(a), ' ', i.Value);
end.


One could also do an alternative (though currently not with arrays, but with 
type helper support even that would be possible...):


Talk about a choice between the plague and cholera...

If I must choose between the proposed extension of for in index do
and having anonymous functions, then I choose for for in index :)
(and most likely ending up with both monstrosities)

Pascal is an explicitly declarative language. 
Anonymous functions go 100% against this. 
It is the readability horror I associate with Javascript.


I often wonder: why do people who seem to think that Pascal misses 
so many - apparently essential - things, even bother to use it ?


If I thought Pascal was missing so many things, I would simply 
use something else instead of trying to turn it into something 
that it is not.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Alexander Klenin

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 for.

If you mean the original Wirth's definition -- then yes, of course any
change to the language
does move it away from the initial state.
However, I am strongly against such a walled garden approach to the
language design.
The state of the art in programming languages has advanced
considerably in the last 40 years,
and the set of features expected from modern language has become quite
different too.
I disagree that freezing at Wirth's (or current, or any fixed)
definition is a useful plan for
Pascal development.

You can always find things missing in any language.
I miss compilation, and other low-level things in Python.
It depends on what you value.
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, this does not mean that disadvantages should be just ignored.

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
opinion on this topic
is again different from the usual one:

Python: google batteries included
C++:
http://stackoverflow.com/questions/5460541/is-the-c-standard-library-part-of-the-c-language
Java: for example, a string literal is defined as an instance of the
java.lang.String class
PHP: it is of course bad design, but for a long time there was not
even a notion of library, all standard methods were accessible
directly at language level
Pascal: note that both the original definition and the ISO standard
include a set of input/output and mathematical functions,
which comprise the standard library. It is a poor library, but
nevertheless included in the language definition.
... etc.

I am talking about libraries that perform actual tasks. Not containers.
PDF generating, https protocol and whatnot. Those are definitely not part of
the language.
Yes, and even those. For example, lack of network support in C++
standard library is
widely considered a disadvantage for the language.
Conversely, presence of such support in Go and Python is hailed as
good language feature.
Note that technically, of course, the distinction exist -- what I am
talking about is that
from user's POV they are the same.

The student will have to remember 4 different syntaxes.

For a:=b to c do
for a:=b downto c do
for a in b do
for a in b index c do

Concise ? I don't think so.

Compared to the 10 methods of iterating over container just in the current
FPC+Lazarus code? Yes, I think this *is* concise and clear.

And let us not forget that the last one is a highly abstract one, because
you need a lot of concepts before you can explain why it is needed and how
to use it. The first one, by contrast, is so simple that any 12-year old can
get it.

Actually, I do teach young students (12 years old is somewhat too
young, but 13-14 is usual).
I can tell you they have *more* trouble with Pascal style of loop with indexing
as compared to Python's for-each with index.

--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread waldo kitty


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:=low(a) to high(a) do
   writeln(i,' ',a[i]);


that's *exactly* what i was going to write in reply but i'm glad i read on and 
saw that someone else had already done so...



Works afaik since TP 6.0.


yep! at least that far back... i use it daily, even today as i try to move more 
and more to FPC... the above is also perfect pascal syntax... a simple and easy 
to read and understand flow :)

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop