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

[Michael Van Canneyt]

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

[Graeme Geldenhuys]

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

[Michael Van Canneyt]

On Fri, 25 Jan 2013, Alexander Klenin wrote:


On Fri, Jan 25, 2013 at 9:36 AM, Michael Van Canneyt
 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

[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

[Michael Van Canneyt]

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

[Mattias Gaertner]

Michael Van Canneyt  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

[Michael Van Canneyt]

On Fri, 25 Jan 2013, Mattias Gaertner wrote:



Michael Van Canneyt  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] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries

[Michael Schnell]

Hi Thomas.

Got it working now.

Thanks a lot for all your help !

(I usually need to understand what is happening before accepting a 
solution.)


In the end I suppose something went wrong some days ago and after I know 
that I need to provide the path to libdl.so, I could do the command line 
correctly and compile your and my projects.


libdl.so in fact is where you suggested:

=
[/opt/arm-none-linux-gnueabi/lib] # ls -l
-rw-r--r--1 adminadminist  654 Feb 14  2012 Mcrt1.o
-rw-r--r--1 adminadminist 1508 Feb 14  2012 Scrt1.o
-rw-r--r--1 adminadminist 1508 Feb 14  2012 crt1.o
-rw-r--r--1 adminadminist 1168 Feb 14  2012 crti.o
-rw-r--r--1 adminadminist  827 Feb 14  2012 crtn.o
-rw-r--r--1 adminadminist 2012 Feb 14  2012 gcrt1.o
drwxr-xr-x2 adminadminist 4096 Jan  3 11:35 ldscripts/
-rwxr-xr-x1 adminadminist27344 Feb 14  2012 libcrypt-2.5.so*
lrwxrwxrwx1 adminadminist   13 Jan  3 11:36 libcrypt.so -> 
libcrypt.so.1*
lrwxrwxrwx1 adminadminist   15 Jan  3 11:36 libcrypt.so.1 -> 
libcrypt-2.5.so*

*-rwxr-xr-x1 adminadminist15192 Feb 14 2012 libdl-2.5.so***
lrwxrwxrwx1 adminadminist 10 Jan  3 11:36 libdl.so -> 
libdl.so.2***
**lrwxrwxrwx1 adminadminist   12 Jan  3 11:36 libdl.so.2 -> 
libdl-2.5.so***

***-rwxr-xr-x1 adminadminist   731885 Feb 14  2012 libm-2.5.so*
lrwxrwxrwx1 adminadminist9 Jan  3 11:36 libm.so -> 
libm.so.6*
lrwxrwxrwx1 adminadminist   11 Jan  3 11:36 libm.so.6 -> 
libm-2.5.so*

-rwxr-xr-x1 adminadminist   135935 Feb 14  2012 libpthread-2.5.so*
lrwxrwxrwx1 adminadminist   15 Jan  3 11:36 libpthread.so -> 
libpthread.so.0*
lrwxrwxrwx1 adminadminist   17 Jan  3 11:36 libpthread.so.0 
-> libpthread-2.5.so*

-rwxr-xr-x1 adminadminist75709 Feb 14  2012 libresolv-2.5.so*
lrwxrwxrwx1 adminadminist   14 Jan  3 11:36 libresolv.so -> 
libresolv.so.2*
lrwxrwxrwx1 adminadminist   16 Jan  3 11:36 libresolv.so.2 
-> libresolv-2.5.so*

-rwxr-xr-x1 adminadminist40684 Feb 14  2012 librt-2.5.so*
lrwxrwxrwx1 adminadminist   10 Jan  3 11:36 librt.so -> 
librt.so.1*
lrwxrwxrwx1 adminadminist   12 Jan  3 11:36 librt.so.1 -> 
librt-2.5.so*

-rwxr-xr-x1 adminadminist13662 Feb 14  2012 libutil-2.5.so*
lrwxrwxrwx1 adminadminist   12 Jan  3 11:36 libutil.so -> 
libutil.so.1*
lrwxrwxrwx1 adminadminist   14 Jan  3 11:36 libutil.so.1 -> 
libutil-2.5.so*

=

I understand that you suggested that the advice to pull libdl.so is in 
dl.pp:


constLibDL = 'dl';
function dlopen(Name : PChar; Flags : longint) : Pointer; cdecl; 
external libdl;


But here (again) I fail to understand how the linker knows that the file 
libdl.so is the target and not dl.o


For me the show-stopper had been that the linker did not complain that 
it did not find a file (i.e. libdl.so) that obviously is requested by an 
appropriate instruction in a pascal unit, but instead complains about 
unresolved externals.


I have no idea what can be done about this behavior, but I think it's 
rather nasty.


Thanks again,
-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]

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

[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

[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

[Mattias Gaertner]

Michael Schnell  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
> >  . 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]

Mattias Gaertner  hat am 25. Januar 2013 um 10:52
geschrieben:
>
> Michael Schnell  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
> > >  . 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

[Michael Schnell]

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

[Michael Van Canneyt]

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

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


-Michael
___
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]

Michael Schnell  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

[Michael Van Canneyt]

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

[Mattias Gaertner]

Michael Schnell  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

[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

[Michael Schnell]

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

[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

[Michael Schnell]

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

[Michael Van Canneyt]

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

[Michael Schnell]

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]

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.



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

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.


-Michael
___
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]

Michael Schnell  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] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries

[Marco van de Voort]

In our previous episode, Thomas Schatzl said:
> The "_init" and "_fini" you need are the ones from libdl.so. The linker
> message doesn't help here. Crt*.o etc. are startup files for gcc
> programs. Can you explain how you got to the impression that you need a
> crti.o that provides _init and _fini? Just curious.

compiler/systems/t_linux:

 if linklibc and (libctype<>uclibc) then
   begin
 { crti.o must come first }
 if librarysearchpath.FindFile('crti.o',false,s) then
   AddFileName(s);
 { then the crtbegin* }

So when the compiler _knows_ it is linking to libc, it will generate a
different link.res than without.

The compiler knows simply if the "c" name appears in the libs to link.

So there are actually four cases:

1. static FPC only application.
2. App that links to a library, but not to "c", and the library has no
reference to libc.
3. App that links to a library, but not to "c", and the library has a
reference to libc.
4. App links to library and C.

Case 1 is all FPC. 

Case 2 strictly speaking too, just passes the linked library to the linker
in link.res but both compiler and linker don't know libc is linked.  So FPC
generates a link.res for non libc linking, and ld probably doesn't link
libc.

In case 3, while FPC doesn't know about the libc linkage, it generates the
link.res like (1). ld knows that something is wrong, and _might_ add c
linking though.

Case 4 is the normal situation for libc linking.

So just to make sure that case 4 is always picked, every lib should have 
a reference to "c". When I reformed the unix lib, the idea was that simply
using "initc" should force that. (thus not having the ifdef block with
linklibs in _every_ header).

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

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

[vrt277]

On 01/25/2013 07:07 PM, Michael Van Canneyt wrote:
The use case presented is SO MARGINAL that it does NOT justify another 
language feature. 
What will you do if you have to iterate through keys of hash table ? c++ 
stl library have own solution for this: iterator returns structure 
called "pair" which have 2 fields. First field contains key and second 
field contains value. (It's similar  to situation when you have to 
return 2 values from function. You can define new type called pair and 
return 2 values. But I doubt someone likes to do it). Now lets compare 
c++stl-like solution and for-in-index loop solution:

c++stl-like solution:
container > iterator > pair (structure stores key-value) -> 
pair.key or pair.value

for-in-loop key solution
container > iterator > key or value


If he wants to help, Alexander  Klenin had better put his students to useful 
tasks.

Actually you(and all other developers of fpc) should do it. I will describe.
I found only one page which describes open issues: 
http://wiki.freepascal.org/Open_tasks. And you can *not* go to this page 
from main page of http://www.freepascal.org/. Looks not very 
contributors-friendly.


Should be you dislike Perl programming language. But visit 
http://www.perl.org/ and first thing that you will see "That's why we 
love Perl 5". They love Perl and they show it. If Freepascal is open 
project then show it. Describe to everyone how he can support fpc.


Best regards,
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

[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

[Graeme Geldenhuys]

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

[Graeme Geldenhuys]

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

[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

[Michael Van Canneyt]

On Sat, 26 Jan 2013, vrt277 wrote:


On 01/25/2013 07:07 PM, Michael Van Canneyt wrote:
The use case presented is SO MARGINAL that it does NOT justify another 
language feature. 
What will you do if you have to iterate through keys of hash table ? c++ stl 
library have own solution for this: iterator returns structure called "pair" 
which have 2 fields. First field contains key and second field contains 
value. (It's similar  to situation when you have to return 2 values from 
function. You can define new type called pair and return 2 values. But I 
doubt someone likes to do it). Now lets compare c++stl-like solution and 
for-in-index loop solution:

c++stl-like solution:
container > iterator > pair (structure stores key-value) -> 
pair.key or pair.value

for-in-loop key solution
container > iterator > key or value


You can do this already. Mattias already showed you how.

Do not let the enumerator return the object, but let it return a record:

Type
  TMyKeyObject = record
Key : TMyKey;
Obj : TMyObj;
  end;

Var
 O : TMyKeyObject;

begin
  For O in MyContainer do
begin
Writeln(O.Key);
Writeln(O.Object.ClassName);
end;

I see nothing wrong with this. It does what you need: return key and value.

If he wants to help, Alexander  Klenin had better put his students to 
useful tasks.
Actually you(and all other developers of fpc) should do it. 


I will describe.
I found only one page which describes open issues: 
http://wiki.freepascal.org/Open_tasks. And you can *not* go to this page from 
main page of http://www.freepascal.org/. Looks not very 
contributors-friendly.


That is funny :-)

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.

So anything you tell me about the wiki not being up-to-date is just funny to me 
:)

Should be you dislike Perl programming language. But visit 
http://www.perl.org/ and first thing that you will see "That's why we love 
Perl 5". They love Perl and they show it. If Freepascal is open project then 
show it. Describe to everyone how he can support fpc.


Well, I already did so in my other replies:

We do not need more language features.

We do need more code libraries.

If you need concrete examples:

- A native Arbitrary-Precision math library is on the list of Alexander Klenin.


From my personal wishlist:

- HTTPS support for fcl-web.
- A complete DBUS solution.
- XML/XSD -> Pascal types (xml mapper from Delphi)
- A PDF rendering engine that does not depend on a GUI.
- Reporting engine that does not depend on a GUI.
- Charting engine that does not depend on a GUI.
- A mechanism to translate Pascal to Javascript. Integrate with Lazarus.
- Lots of web & database tools.
- A way to design native Java bytecode Android apps in Lazarus.

For many things the start of the building blocks are there.

I'm sure there are many more things. Feel free to put them in the WIKI ;)

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


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

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

[Graeme Geldenhuys]

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

[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

[Michael Van Canneyt]

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

[Alexander Klenin]

On Fri, Jan 25, 2013 at 7:07 PM, Michael Van Canneyt
 wrote:
> WITH EACH ADDITIONAL "FEATURE" WE ARE BUTCHERING PASCAL MORE AND MORE.
Hm... Do not you think this is a bit of an overstatement?

> 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 TArrayIterator;
  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

[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

[Florian Klämpfl]

Am 25.01.2013 17:18, schrieb Alexander Klenin:
> On Fri, Jan 25, 2013 at 7:07 PM, Michael Van Canneyt
>  wrote:
>> WITH EACH ADDITIONAL "FEATURE" WE ARE BUTCHERING PASCAL MORE AND MORE.
> Hm... Do not you think this is a bit of an overstatement?
> 
>> 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

[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

[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

[Alexander Klenin]

On Sat, Jan 26, 2013 at 3:30 AM, Florian Klämpfl  wrote:
>> "for-in-index" extension was actually planned by me as a prerequisite
>> for fcl-stl work.
>
> Using indicies is against all principles of iterators.
I am not sure what princilpes you are talking about,
but accessing the key of the current element is required quite often
and provided by iterator implementations in many programming languages
(except for Java, as discussed above).
I have already provided examples.

> 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.
This is true, but was no relevance to the syntax extension discussed here.
Note that there is no limitation on the type of index,
and of course it is not required that the indices are monotonously
increasing integers.

>> 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.
2) If "a" is a function of another complex expression returning an
array, then "for-in" may be much more efficient and compact
3) If "a" is an associative array (so i is a String), then the
"traditional" form of loop is not even possible.
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.

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

[Michael Van Canneyt]

On Sat, 26 Jan 2013, Alexander Klenin wrote:


On Fri, Jan 25, 2013 at 7:07 PM, Michael Van Canneyt
 wrote:

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

Hm... Do not you think this is a bit of an overstatement?


No, not really. 
I really feel that we are deviating a lot from what pascal stands for.



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.


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.


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.


Great news !




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.


You could have asked in advance and be spared the disappointment.




Pascal needs more useful libraries.

It is important to note that default libraries ARE part of the language


You are wrong there.

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.



and from the user's POV language vs library distinction is an irrelevant detail.


We have different ideas of what libraries are. 
The STL is not what I have in mind when I speak about a library.



What is important is a clear, concise and easy-to-remember syntax.


Exactly. But we seem to have different ideas about what that is.

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.

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.


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

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

[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

[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

[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 TArrayIterator;
   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
  TFPGMap = 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 TFPGMap;
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

[Florian Klämpfl]

Am 25.01.2013 18:17, schrieb Alexander Klenin:
> On Sat, Jan 26, 2013 at 3:30 AM, Florian Klämpfl  
> wrote:
>>> "for-in-index" extension was actually planned by me as a prerequisite
>>> for fcl-stl work.
>>
>> Using indicies is against all principles of iterators.
> I am not sure what princilpes 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

[Michael Van Canneyt]

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 TArrayIterator;
   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

[Alexander Klenin]

On Sat, Jan 26, 2013 at 4:38 AM, Michael Van Canneyt
 wrote:
>>> WITH EACH ADDITIONAL "FEATURE" WE ARE BUTCHERING PASCAL MORE AND MORE.
>> Hm... Do not you think this is a bit of an overstatement?
> No, not really. I really feel that we are deviating a lot from what pascal 
> stands for.

If you 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

[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

[Michael Van Canneyt]

On Sat, 26 Jan 2013, Alexander Klenin wrote:


On Sat, Jan 26, 2013 at 4:38 AM, Michael Van Canneyt
 wrote:

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

Hm... Do not you think this is a bit of an overstatement?

No, not really. I really feel that we are deviating a 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.


I don't see it like that. Donald Knuth declared TeX as finished.
Despite that, it has been doing just fine for its intended purpose.


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.


I didn't say that.

Like I said, I am not against new language features per se.
I just don't think that this one is one that should be added.


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:


If I cared about 'usual opinion', I would be using C#.


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.


There is only 1 method:

for i:=0 to I.Count-1.


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.


You want to tell me that

for i:=1 to 10 do
  Writeln(i);

is less clear than

for i in range(1,10)
  printf(i) # or whatever python uses.

For someone versed in Python, I can imagine that probably is so.

But I learned from BASIC, and had absolutely no problem understanding 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

[Sven Barth]

On 25.01.2013 19:32, Michael Van Canneyt wrote:



On Fri, 25 Jan 2013, Sven Barth wrote:


On 25.01.2013 17:18, Alexander Klenin wrote:

With this in mind, consider a user who wants to iterate over the
following array:

var
   a: array [1..5] of Integer = (1, 2, 9, 4, 5);

In my proposal, he 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 TArrayIterator;
   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...



I know why I first added the example with a normal (nested) procedure.


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)


Though it might be easier to "fight" against the "for-in-index" as 
anonymous functions are supported by Delphi... ;)




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



The syntax is indeed very ugly. I personally would prefer real lambda 
expressions(!) more. To use the example from my previous mail:


=== example begin ===

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


=== example end ===

I'm in so far in favor of anonymous methods (or lamda expressions) as 
they allow you to keep the logic together (in the example the fact of 
iterating with what the iteration does). Another example which would 
apply to TThread (I'll use my lamdba syntax again):


=== example begin ===

Queue(lamda TProc as fSomeReferencedMemo.Lines.Add(fSomeText));

=== example end ===

I think this is more understandable/readable than having to add a 
"AddTextToMemo" method and a "fTextToAdd" field and then 
Synchronize/Queue that method...



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



I personally wouldn't call many of these features essential, this 
includes anonymous functions and helper types equally. You can achieve 
what they provide yourself, but if the compiler aids you with this, you 
can move a part of the responsibility for correct code to the compiler 
(which should be considered a good think from the POV of a user) and it 
can also increase the readability.



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.


Languages evolve. Natural languages as well as programming languages. We 
might not agree with every change (e.g. in German there has been 
established the nasty habit of saying "that makes sense" ("das macht 
Sinn") while the correct equivalent would be "that has sense" ("das hat 
Sinn") or "that is sensful" ("das ist sinnvoll")), but we can not stop 
this evolution. Languages that don't evolve are dead, because noone 
speaks them anymore (as everyone will always add his one character to 
the language, though granted this is not as easy for programming 
languages as you need to work in the compiler/interpreter). Hadn't 
Borland decided to bring out Delphi and thus the completely different 
object model (which I personally think is in most points superior to TP 
style objects, to those have their pros, too), but instead kept e.g. 
Turbo Pascal for Windows we might not be talking together here today.


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

[Alexander Klenin]

On Sat, Jan 26, 2013 at 5:12 AM, Daniël Mantione
 wrote:
>> Consider these arguments:
>> 1) Even for simple arrays, depending on array element type,
>>  and optimizer implementation, for-in can be more efficient since it
>> can avoid multiplication for 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.
I argee. Still, for the general container such an optimization is
hard-to-impossible to implement.

>> 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.
"with" statement of of course not help (try it).
CSE might help, but is tricky across function boundaries -- function
must be first proven to be pure,
which is non-trivial in Pascal.
temp variable is, of course, always a solution -- but so is using while loop
or even labels and goto. I am tying to make Pascal higher-level language,
as opposed to, e.g. C, which is determined to stay at low level.

>> 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).
Please try to define a mapping between String and Integer :)

>> 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'].
First, for-in loop is not a for-loop. It is unfortunate that due to the need to
avoid new reserved words, "for" war chosen instead of more logical
"foreach" or even "for each".
But nevertheless, they should not be confused.
Similarly, I have chosen "index" instead of more logical "key",
which tricked some developers into thinking that I am talking about
indeger indexes only.
Second, accessing the associative array element via key has non-trivial cost,
which is avoided by using foreach-type loops.

> 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.
"fundamentalistic" is a right word here.

> 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.
I do not see why it is broken -- only because it is contrary to the
fundamentalist view?

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

[Sven Barth]

On 25.01.2013 19:59, Michael Van Canneyt wrote:



On Sat, 26 Jan 2013, Alexander Klenin wrote:

Pascal needs more useful libraries.

It is important to note that default libraries ARE part of the language

You are wrong there.

Well, this is a matter of opinion of course, but note that your
opinion on this topic is again different from the usual one:


If I cared about 'usual opinion', I would be using C#.



Or Java ^^


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.


There is only 1 method:

for i:=0 to I.Count-1.


I think he also means things like (without critizing):

MyDataSet.First;
while not MyDataset.Eof do begin
  // ...
  MyDataSet.Next;
end;
// on a sidenote: what about a TDataSet enumerator? :)

for i := 0 to MyWinControl.ChildCount - 1 do
  // ...

for i := 0 to MyWinControl.ControlCount - 1 do
  // ...

There might be more, but I don't remember them currently... :(

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

[Alexander Klenin]

On Sat, Jan 26, 2013 at 6:11 AM, Sven Barth  wrote:
> I think he also means things like (without critizing):

Yes, thank for a dose of sanity :)

Few more examples, taken from just one standard package:

while Node.NextBrother<>nil do begin
  ...
  Node:=Node.NextBrother;
end;

while Node<>nil do begin
  ...
  Node:=Node.Next;
end;

while Node<>nil do begin
  ...
  Node:=Node.NextSibling;
end;

while Result<>nil do begin
  ...
  Result:=Result.NextError;
end;

> MyDataSet.First;
> while not MyDataset.Eof do begin
>   // ...
>   MyDataSet.Next;
> end;
> // on a sidenote: what about a TDataSet enumerator? :)

It is not clear what should loop variable contain:
for v in MyDataSet do ... -- what is v?

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

[Daniël Mantione]

Op Sat, 26 Jan 2013, schreef Alexander Klenin:


On Sat, Jan 26, 2013 at 5:12 AM, Daniël Mantione
 wrote:

Consider these arguments:
1) Even for simple arrays, depending on array element type,
 and optimizer implementation, for-in can be more efficient since it
can avoid multiplication for 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.

I argee. Still, for the general container such an optimization is
hard-to-impossible to implement.


?? For the general container figher['ninja'] would not be implemented by 
multiplication.



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.

"with" statement of of course not help (try it).


If you cannot use with directly, wrap the array inside a record.


CSE might help, but is tricky across function boundaries -- function
must be first proven to be pure,
which is non-trivial in Pascal.
temp variable is, of course, always a solution -- but so is using while loop
or even labels and goto. I am tying to make Pascal higher-level language,
as opposed to, e.g. C, which is determined to stay at low level.


I understand your goal, which is commendable. The challenge is to do it in 
a way that doesn't turn Pascal in something it is not.



Please try to define a mapping between String and Integer :)


const integer2fighter:array[0..3] of 
string=('knight','ninja','samurai','swordman');

function fighter2integer(const s:string):integer;

begin
  {implement binary search}
end;



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

First, for-in loop is not a for-loop. It is unfortunate that due to the need to
avoid new reserved words, "for" war chosen instead of more logical
"foreach" or even "for each".
But nevertheless, they should not be confused.
Similarly, I have chosen "index" instead of more logical "key",
which tricked some developers into thinking that I am talking about
indeger indexes only.
Second, accessing the associative array element via key has non-trivial cost,
which is avoided by using foreach-type loops.


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.

"fundamentalistic" is a right word here.


Yes... because it's wrong to always stick to principles if practical 
problems are to be solved. But it's also wrong to add too much pragmatic 
exceptions: With software it becomes hard to maintain, with programmings 
languages it becomes unelegant and hard to learn.


Pascal was such a breakthough in the 1970's because of its elegance. That 
should always be kept in mind when extending the language. (And has been 
forgotten too often unfortunately.)



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.

I do not see why it is broken -- only because it is contrary to the
fundamentalist view?


Bottom line: yes. Language design is a lot about esthetics. Having many 
syntaxes for things as simple as a for loop is bad tasted. The amount of 
syntax is getting out of hand.


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

[Sven Barth]

On 25.01.2013 20:24, Alexander Klenin wrote:

MyDataSet.First;
while not MyDataset.Eof do begin
   // ...
   MyDataSet.Next;
end;
// on a sidenote: what about a TDataSet enumerator? :)


It is not clear what should loop variable contain:
for v in MyDataSet do ... -- what is v?


Right... forget that idea. (so much for sanity ^^)

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

[Alexander Klenin]

On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl  wrote:
> Am 25.01.2013 18:17, schrieb Alexander Klenin:
>>> Using indicies is against all principles of iterators.
>> I am not sure what princilpes you are talking about,
>
> The theory of iterators.

You mean Alexander Stepanov's ideas which served as a basis for STL?
If so, you may notice that STL does include the concept of 
pair which is returned by iterators on maps.
Also note that Pascal and C++ is are quite different designs --
C++ usually sacrifices readability for the sake of reducing the number
of language features,
while Pascal traditionally followed an opposite direction.
(E.g. built-in String vs, std::string).
So while with the latest improvements to the generics it is almost possible
to replicate C++ STL design, I think that it is not correct way.
I would prefer the approach of Go language, which does include direct
syntax support for
the most often used constructs even if they can be simulated using libraries.
For example, I do think that despite existence of fcl-stl, Pascal
would benefit from direct
inclusion of simple associative arrays:
var a: array [String] of Integer;
Yes, it is a duplication of concepts, but it would make a life of a
programmer simpler.

>> I have already provided examples.
>
> Where? Concrete code of a serious language! Not some "oh, yes, this
> language has it and that as well"
I am afraid that it is very hard for me to discuss against such statements.
Do you consider Java "serious" while Python, Ruby, PHP, Objective C
etc "not serious"?
What is "concrete code"? The code I provided only missed loop bodies.
I can provide that too, but I do not think it will add anything to the
discussion.

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

[Sven Barth]

On 25.01.2013 20:54, Alexander Klenin wrote:

I have already provided examples.


Where? Concrete code of a serious language! Not some "oh, yes, this
language has it and that as well"

I am afraid that it is very hard for me to discuss against such statements.
Do you consider Java "serious" while Python, Ruby, PHP, Objective C
etc "not serious"?
What is "concrete code"? The code I provided only missed loop bodies.
I can provide that too, but I do not think it will add anything to the
discussion.


I believe he wants to have real world examples (of other languages) 
where this feature is used. E.g. in some well respected software, 
library, 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

[Mark Morgan Lloyd]

Sven Barth wrote:

Languages evolve. Natural languages as well as programming languages. We 
might not agree with every change (e.g. in German there has been 
established the nasty habit of saying "that makes sense" ("das macht 
Sinn") while the correct equivalent would be "that has sense" ("das hat 
Sinn") or "that is sensful" ("das ist sinnvoll")), but we can not stop 
this evolution. Languages that don't evolve are dead, because noone 
speaks them anymore (as everyone will always add his one character to 
the language, though granted this is not as easy for programming 
languages as you need to work in the compiler/interpreter). Hadn't 
Borland decided to bring out Delphi and thus the completely different 
object model (which I personally think is in most points superior to TP 
style objects, to those have their pros, too), but instead kept e.g. 
Turbo Pascal for Windows we might not be talking together here today.


I'm not sure that I should venture an opinion, since my ability to 
implement something- to "practice what I preach"- is limited due to my 
position on the learning curve.


However, I'd suggest that there are two possible category of extension: 
those that implement a clearly-delimited first-class object with 
interesting properties, and those that don't.


Something like a , or a /regular expression/ (borrowing from 
Perl), or a [list of elements] fall into the first category, and should 
be comparatively easy to add to a language- and for a user to ignore if 
he doesn't like them.


Something like

for a in a index i do

falls squarely into the latter category: it's messy to parse, worse to 
read, and is completely unlike any existing language idioms.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

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

[Alexander Klenin]

On Sat, Jan 26, 2013 at 6:59 AM, Sven Barth  wrote:
>> What is "concrete code"? The code I provided only missed loop bodies.
>> I can provide that too, but I do not think it will add anything to the
>> discussion.
>
> I believe he wants to have real world examples (of other languages) where
> this feature is used. E.g. in some well respected software, library, etc.

Thank you, I understand now.
Python:
https://www.google.com/search?q=site%3Agithub.com+for+%22in+enumerate%22
PHP:
https://www.google.com/search?q=site%3Agithub.com+foreach(%24a+as+%24k+%3D%3E+%24v)
Objective C:
https://www.google.com/search?q=site%3Agithub.com+enumerateObjectsUsingBlock
JavaScript:
https://www.google.com/search?q=site%3Agithub.com+%22forEach(function(value%2C+index%22

Note that I restricted search to a single repository site to avoid
catching various manuals and discussions.
I had also fix parameter names for some languages, because Google does
not support regexp search.
Even with those limitations, you may notice that each search returns
thousands of results.
I do not wish to enter an argument about how "respected" those
languages and projects are --
but I hope it demonstrates unambiguously the popularity of the feature.

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

[Florian Klämpfl]

Am 25.01.2013 21:18, schrieb Alexander Klenin:
> On Sat, Jan 26, 2013 at 6:59 AM, Sven Barth  
> wrote:
>>> What is "concrete code"? The code I provided only missed loop bodies.
>>> I can provide that too, but I do not think it will add anything to the
>>> discussion.
>>
>> I believe he wants to have real world examples (of other languages) where
>> this feature is used. E.g. in some well respected software, library, etc.
> 
> Thank you, I understand now.

No. I want to see a language which provides something like the  explicit
index keyword and not some tupel returning enumerator like python which
can be done already.

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

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

[Alexander Klenin]

On Sat, Jan 26, 2013 at 7:10 AM, Mark Morgan Lloyd
 wrote:
> However, I'd suggest that there are two possible category of extension:
> those that implement a clearly-delimited first-class object with interesting
> properties, and those that don't.
>
> Something like a , or a /regular expression/ (borrowing from Perl),
> or a [list of elements] fall into the first category, and should be
> comparatively easy to add to a language- and for a user to ignore if he
> doesn't like them.
I disagree with the statement that generics are easy to add.
I disagree with a statement that adding Perl's first-class regexp
syntax is a good idea at all --
talk about messy parsing :)
I agree that [list of elements] is a good feature, but it is already present.
So, unfortunately, I can not accept your list as an example of "good"
extensions.

> Something like
>for v in a index i do
> falls squarely into the latter category: it's messy to parse, worse to read,
I disagree with the statement that "for-in-index" loop is "messy to parse".
You can look at the code provided by Vasily: there is no problem in
parsing at all.
The question of readabllity is indeed subjective, and I am quite open
for altervative proposals here.
The current syntax was chosen based on the requirements to avoid new
keywords and traditional
Pascal preference for keywords over punctuation.
However, I may consider variants below (v = value, i = index, a = array):
for v, i in a do
for i, v in a do // most similar to Python
for (v, i) in a do
for v[i] in a do
for v index i in a do // perhaps this is really better -- I am not sure
for index i in a do // we may allow to omit the value and loop only
over the index -- this could be useful for STL sets
for v key i in a do // new keyword = bad

> and is completely unlike any existing language idioms.
Do you mean idioms existing in Pascal, or general language idioms?

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

[Sven Barth]

On 25.01.2013 21:10, Mark Morgan Lloyd wrote:

Something like

 for a in a index i do

falls squarely into the latter category: it's messy to parse, worse to
read, and is completely unlike any existing language idioms.



I definitely have to disagree here (while still not having an opinion on 
the topic "for-in-index" itself): once you've worked on Delphi style 
generics you know what messy parsing is... and I already get nightmares 
thinking about what I still need to add for Delphi's generics support... 
This for-in-index is a peace of cake to parse in comparison.


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

[Alexander Klenin]

On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl  wrote:
> Where? Concrete code of a serious language! Not some "oh, yes, this
> language has it and that as well"

On Sat, Jan 26, 2013 at 7:34 AM, Florian Klämpfl  wrote:
> No. I want to see a language which provides something like the  explicit
> index keyword and not some tupel returning enumerator like python which
> can be done already.

Oh, I see. Please, state your questions more clearly -- there is no
way I could infer
the second question from the first one!
There are two answers here:
1) If you would look at the examples I provided, you would notice that
while Python
(and C++ which I did not list) do use the concept of tuple, other
listed languages do not.

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

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.

With this proposal, following benefits are gained:

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

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

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

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

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.

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

[Florian Klämpfl]

Am 25.01.2013 22:44, schrieb Alexander Klenin:
> On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl  
> wrote:
>> Where? Concrete code of a serious language! Not some "oh, yes, this
>> language has it and that as well"
> 
> On Sat, Jan 26, 2013 at 7:34 AM, Florian Klämpfl  
> wrote:
>> No. I want to see a language which provides something like the  explicit
>> index keyword and not some tupel returning enumerator like python which
>> can be done already.
> 
> Oh, I see. Please, state your questions more clearly -- 

Maybe I wouldn't have to ask if there would be a clear proposal what
shall be implemented, what are alternatives, what do other languages,
why is a so strange approach chosen etc.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

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

[waldo kitty]

On 1/25/2013 13:59, Michael Van Canneyt wrote:

On Sat, 26 Jan 2013, Alexander Klenin wrote:

I certainly agree that Pascal has some advantages -- and they often
outweigh disadvantages.
Otherwise, I would be in Python's mailing list now, arguing to add
some of the Pascal's features :)
However, this does not mean that disadvantages should be just ignored.


I didn't say that.

Like I said, I am not against new language features per se.
I just don't think that this one is one that should be added.


FWIW (littlest pup in the pack): i agree with this... the discussion looks to me 
like something one would find in their own local library code... but then again, 
i'm a little pup here... very little...


/me looks at all his library files of routines and functions and considers how 
many routines there are in there and how long it took to work them out...

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

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

[Alexander Klenin]

On Sat, Jan 26, 2013 at 8:54 AM, Florian Klämpfl  wrote:
> Maybe I wouldn't have to ask if there would be a clear proposal what
> shall be implemented, what are alternatives, what do other languages,
> why is a so strange approach chosen etc.

I agree that the quality of initial proposal could be better.
In my defense I could say that it is still better than for (almost?)
any other feature implemented in the last couple of years.

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

[Mark Morgan Lloyd]

Sven Barth wrote:

On 25.01.2013 21:10, Mark Morgan Lloyd wrote:

Something like

 for a in a index i do

falls squarely into the latter category: it's messy to parse, worse to
read, and is completely unlike any existing language idioms.



I definitely have to disagree here (while still not having an opinion on 
the topic "for-in-index" itself): once you've worked on Delphi style 
generics you know what messy parsing is... and I already get nightmares 
thinking about what I still need to add for Delphi's generics support... 
This for-in-index is a peace of cake to parse in comparison.


I wasn't trying to say that it was easy so much as it would have been 
worse if it weren't for the unambiguous delimiters.


In fact I bet that with what you know now you'd be able to move generic 
support into a run-time library loaded when the <> idiom was recognised.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

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

[Sven Barth]

On 25.01.2013 22:44, Alexander Klenin wrote:

On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl  wrote:

Where? Concrete code of a serious language! Not some "oh, yes, this
language has it and that as well"


On Sat, Jan 26, 2013 at 7:34 AM, Florian Klämpfl  wrote:

No. I want to see a language which provides something like the  explicit
index keyword and not some tupel returning enumerator like python which
can be done already.


Oh, I see. Please, state your questions more clearly -- there is no
way I could infer
the second question from the first one!
There are two answers here:
1) If you would look at the examples I provided, you would notice that
while Python
(and C++ which I did not list) do use the concept of tuple, other
listed languages do not.

2) Indeed, introducing tuples to Pascal might be an alternative
solution. Below is a proposal:


Regarding tuples:
http://wiki.oxygenelanguage.com/en/Tuples

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

[Sven Barth]

On 25.01.2013 23:20, Mark Morgan Lloyd wrote:

Sven Barth wrote:

On 25.01.2013 21:10, Mark Morgan Lloyd wrote:

Something like

 for a in a index i do

falls squarely into the latter category: it's messy to parse, worse to
read, and is completely unlike any existing language idioms.



I definitely have to disagree here (while still not having an opinion
on the topic "for-in-index" itself): once you've worked on Delphi
style generics you know what messy parsing is... and I already get
nightmares thinking about what I still need to add for Delphi's
generics support... This for-in-index is a peace of cake to parse in
comparison.


I wasn't trying to say that it was easy so much as it would have been
worse if it weren't for the unambiguous delimiters.



After implementing support for Delphi style generics I came to the 
conclusion that I would have preferred the following syntax:


type
  TFPGListLongInt = specialize TFPGList as (Integer);

or

type
  TFPGListLongInt = specialize TFPGList with (Integer);

This could also have appeared inline without to many headaches. For the 
first one the "specialize" keyword would have definitely been necessary, 
but for second syntax idea it would have worked without the "specialize" 
keyword as well...



In fact I bet that with what you know now you'd be able to move generic
support into a run-time library loaded when the <> idiom was recognised.



No, I wouldn't. This would make the code in no way more maintainable or 
even more understandable. Quite the contrary.


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

[Alexander Klenin]

On Sat, Jan 26, 2013 at 9:27 AM, Sven Barth  wrote:
>
> Regarding tuples:
> http://wiki.oxygenelanguage.com/en/Tuples
I know, but I consider this particular implementation an unpleasant example of
"no need to change the language -- lets do it in the library" philosophy.
Just look:
>The Tuple type 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.

Also, the feature set is rather weak compared to my proposal, to the
point of not worthing it.
Still, if my proposal would be implemented, it is will also become
possible in FPC to allow
anonymous records as return types -- the user will have to use tuples
to deconstruct them.

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

[Alexander Klenin]

On Sat, Jan 26, 2013 at 9:31 AM, Sven Barth  wrote:
> After implementing support for Delphi style generics I came to the
> conclusion that I would have preferred the following syntax:
>
> type
>   TFPGListLongInt = specialize TFPGList as (Integer);
>
> or
>
> type
>   TFPGListLongInt = specialize TFPGList with (Integer);
>

Whatever the particular syntax, I do agree that the decision to use
angular brackets
was unnecessarily copied from C++ -- round ones (or, at least, square
ones) would be much better.

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

[Marco van de Voort]

In our previous episode, Alexander Klenin said:
> On Sat, Jan 26, 2013 at 9:31 AM, Sven Barth  
> wrote:
> >   TFPGListLongInt = specialize TFPGList with (Integer);
> >
> 
> Whatever the particular syntax, I do agree that the decision to use
> angular brackets
> was unnecessarily copied from C++ -- round ones (or, at least, square
> ones) would be much better.

Delphi got its generics from .NET. The .NET compiler got it one version
earlier. (D2007, native D2009)

Probably the main reason for generics was access the 2.0 framework which was
new (and used generics) going from D2006 to D2007
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

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

[Alexander Klenin]

On Sat, Jan 26, 2013 at 5:17 AM, Sven Barth  wrote:
> One could also do an alternative (though currently not with arrays, but with
> type helper support even that would be possible...):

Yes, this is certainly the most interesting alternative. Actually,
anonymous procedures/closures
is the "real" task I wanted Vasily to perform, after the "warm-up" of
for-in-index.
I am still of the opinion that "for-in-index" would be a good addition
nevertheless,
because it is a simple and neat solution for 90% of the cases, so even
if there exists
a general and complex solution for 100%, IMHO simple one is still worth having.

Nevertheless, I separated the thread to discuss anonymous procedures,
hopefully with less flame, or at least, with flame of different colours :)

When comparing anonymous procedures with built-in for-in loop,
it is important to consider the code speed.
I think that good support for inlining "Iterate" procedure *together
with its argument*
is essential for anonymous procedures to be a competitive solution for
the problem
of container iteration.

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

As you noted, this solution is conceptually good, but rather cumbersome to write

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

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;

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:
procedure p(a, b: Integer);
p(3, 5); // Traditional syntax
p :3 :5; // Proposed extension
Then, then code will be

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

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

which is as good as it gets, IMHO.

> And for a given array type and type helper support you can do the following:
While type helpers are a neat idea, I fear they introduce too much
"action at a distance"
for so frequent usage.
A global generic functions (they are planned anyway, aren't they?)
will be sufficient:

Iterate :map :lambda
  Writeln(aKey, ' => ', aData.ClassName);
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

[Alexander Klenin]

On Sat, Jan 26, 2013 at 9:50 AM, Marco van de Voort  wrote:
>> Whatever the particular syntax, I do agree that the decision to use
>> angular brackets
>> was unnecessarily copied from C++ -- round ones (or, at least, square
>> ones) would be much better.
>
> Delphi got its generics from .NET. The .NET compiler got it one version
> earlier. (D2007, native D2009)
>
> Probably the main reason for generics was access the 2.0 framework which was
> new (and used generics) going from D2006 to D2007

Quite probably, but that is still no reason for angular brackets :)

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

[Marco van de Voort]

In our previous episode, Alexander Klenin said:
> > Probably the main reason for generics was access the 2.0 framework which was
> > new (and used generics) going from D2006 to D2007
> 
> Quite probably, but that is still no reason for angular brackets :)

Maybe. But like many extensions, multiple distinct ways to do stuff is even
worse.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

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

[Paul Ishenin]

26.01.13, 2:32, Michael Van Canneyt пишет:


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


I wonder where you were when Operators feature has been added to pascal? 
Or generics?


I think now when 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.


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

[Paul Ishenin]

26.01.13, 4:47, Sven Barth пишет:


I definitely have to disagree here (while still not having an opinion on
the topic "for-in-index" itself): once you've worked on Delphi style
generics you know what messy parsing is... and I already get nightmares
thinking about what I still need to add for Delphi's generics support...
This for-in-index is a peace of cake to parse in comparison.


I confirm. When I tried think how to add delphi like generic parse to 
language I also had this nightnares. As result I simple stoped to work 
on 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

[Hans-Peter Diettrich]

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.

DoDi


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