Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: Hm. I like this direction of thinking, yes... Hm. I like that after 100 mails of 'yes, I like them', 'no, I don't like them' we finnaly moved to the initial idea of the tread - design and implementation discussion :) What about function StepNext: Boolean; iterator 'movenext'; property TheCurrentValue: Integer; iterator 'current'; string are bad. or better yet, because it is more strict: function StepNext: Boolean; iterator nextvalue; property TheCurrentValue: Integer; iterator currentvalue; I like this one. Only not 'iterator nextvalue' and 'iterator currentvalue' but 'iterator movenext' and 'iterator current' :) Or 'enumerator' instead of 'iterator' to be compatible with delphi terminology ;) Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: LAMBDA
Jeff Wormsley pisze: Michael Schnell wrote: Again something inspired by Delphi-Prism ? ( http://prismwiki.codegear.com/en/Lambda_Expressions ) Wow, talk about unreadable code... why all vote about something, that wasn't proposed ? -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Paul Ishenin pisze: Marc Weustink wrote: I can see a use for using iterators in a for loop, however they should be declared with some keyword. Something like type TListIterator = iterator(TList, init_func, next_func, check_func) function init_func: Boolean; function next_func: function check_func: Boolean; end; begin for element in list using TListIterator do... IMO this is more pascal than using some interface or predefined function names. Good idea. What is iterator internally? Is this an object with the special header? Is it internall the same as: TListIterator = object function init_func(AList: TList): Boolean; function next_func: Pointer; function check_func: Boolean; end; But where is current state of iterator. next_func need to know old state and then easy move to next, but were state is saved. second solution receive old result, find it in collection, decode past state and compute next, but it hurt performance -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt schrieb: > My only worry now is to make sure that if they are implemented, that we > make the design as clean as possible: e.g. No hardcoded dependencies on > class or > interface names. > Afaik Delphi's implementation only depends on the guid: it's the same as interface ref. counting. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Micha Nelissen pisze: Michael Van Canneyt wrote: I see little gain in changing while Something(f) do F.Somethingelse This is not quite equal, it's more like: Start(f); while not Last(f) do F.DoWork; In your case, the function 'Something' must know about a generic F. why not f.start; while not f.last do f.doWork; There are also recursive state problems to be thought about. I guess this is why in the STL an iterator is a separate object on the local stack, but able to iterate through (another) object of the defined type. Second problem is multithreading, when we try to iterate concurrent on the same collection. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics
On Thu, Oct 22, 2009 at 04:08, David B Copeland wrote: > In what way is Generics not 100%? > > Dave Copeland. For me at least, the gravest problem is a lack of function-level generics. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics
On Wed, 2009-10-21 at 15:54 +0200, Jonas Maebe wrote: > On 21 Oct 2009, at 14:55, Marco van de Voort wrote: > > Generics still don't work 100%, > > > Jonas > In what way is Generics not 100%? Dave Copeland. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Alexander Klenin wrote: On Thu, Oct 22, 2009 at 02:07, Sergei Gorelkin wrote: As I tried to say earlier, having distinct StepNext() and Current() functions is somewhat redundant, except the purpose of Delphi compatibility. Rationale: the for..in loop manages the iterator object itself, and does not allow user code inside the loop to access the iterator and call its methods. Therefore, it is possible to reduce the whole thing to: function Next(out value: SomeType): Boolean; iterator; thus eliminating the need for additional qualifiers after 'iterator'. This is slightly better, but IMO does not worth additional incompatibility. Also, your proposal is far less extendable: 1) Delphi iterators have also magic 'Reset' function which is easy to express by attribute "iterator reset", but hard to express in your proposal Reset is probably targeted for using iterators 'standalone'. I don't see how it fits into the for..in loop, which does not provide access to the iterator object. 2) See the end of the for-in wiki page for my proposal for optional "iterator index" extension, which is also non-trivial to do in your proposal. I doubt in usefulness of the iterator index. The iterators are, by definition, targeted for containters that are not indexable, otherwise just access container elements by index and be done with it. Attempting to introduce the index, at best you get a simple counter, at worst there will be some number dependent on particular iteration method, so that a single element gets different index in different situations. Anyway, if the container is non-indexable, this index has no further use. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Thu, Oct 22, 2009 at 02:07, Sergei Gorelkin wrote: > As I tried to say earlier, having distinct StepNext() and Current() > functions is somewhat redundant, except the purpose of Delphi compatibility. > Rationale: the for..in loop manages the iterator object itself, and does not > allow user code inside the loop to access the iterator and call its > methods. Therefore, it is possible to reduce the whole thing to: > > function Next(out value: SomeType): Boolean; iterator; > > thus eliminating the need for additional qualifiers after 'iterator'. This is slightly better, but IMO does not worth additional incompatibility. Also, your proposal is far less extendable: 1) Delphi iterators have also magic 'Reset' function which is easy to express by attribute "iterator reset", but hard to express in your proposal 2) See the end of the for-in wiki page for my proposal for optional "iterator index" extension, which is also non-trivial to do in your proposal. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Wed, 21 Oct 2009, Sergei Gorelkin wrote: Michael Van Canneyt wrote: Hm. I like this direction of thinking, yes... What about function StepNext: Boolean; iterator 'movenext'; property TheCurrentValue: Integer; iterator 'current'; or better yet, because it is more strict: function StepNext: Boolean; iterator nextvalue; property TheCurrentValue: Integer; iterator currentvalue; In this way, it's more like some extra modifiers. (so like safecall, default, stored and whatnot) It just adds some modifiers, and we're free of hard-coded names. With one of these I could live :-) As I tried to say earlier, having distinct StepNext() and Current() functions is somewhat redundant, except the purpose of Delphi compatibility. Rationale: the for..in loop manages the iterator object itself, and does not allow user code inside the loop to access the iterator and call its methods. Therefore, it is possible to reduce the whole thing to: function Next(out value: SomeType): Boolean; iterator; thus eliminating the need for additional qualifiers after 'iterator'. If this is possible, it is even better... The main thing is: no hardcoded names... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: Hm. I like this direction of thinking, yes... What about function StepNext: Boolean; iterator 'movenext'; property TheCurrentValue: Integer; iterator 'current'; or better yet, because it is more strict: function StepNext: Boolean; iterator nextvalue; property TheCurrentValue: Integer; iterator currentvalue; In this way, it's more like some extra modifiers. (so like safecall, default, stored and whatnot) It just adds some modifiers, and we're free of hard-coded names. With one of these I could live :-) As I tried to say earlier, having distinct StepNext() and Current() functions is somewhat redundant, except the purpose of Delphi compatibility. Rationale: the for..in loop manages the iterator object itself, and does not allow user code inside the loop to access the iterator and call its methods. Therefore, it is possible to reduce the whole thing to: function Next(out value: SomeType): Boolean; iterator; thus eliminating the need for additional qualifiers after 'iterator'. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Thu, 22 Oct 2009, Alexander Klenin wrote: On Thu, Oct 22, 2009 at 01:44, Michael Van Canneyt wrote: What about function StepNext: Boolean; iterator 'movenext'; property TheCurrentValue: Integer; iterator 'current'; You beat me by two minutes ;-) function StepNext: Boolean; iterator nextvalue; property TheCurrentValue: Integer; iterator currentvalue; I do not care much, but putting names in quotes may slightly simplify parser, IMO. I think exactly the opposite, but I don't think the quotes are so relevant. I have a preference for no quotes, but that is a matter of taste. With quotes it would more resemble the "message" modifier... Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Paul Ishenin wrote: Michael Van Canneyt wrote: My only worry now is to make sure that if they are implemented, that we make the design as clean as possible: e.g. No hardcoded dependencies on class or interface names. We need to count the pros and contras first regards hardcoded names and maybe 'hard coded' code. For example for me the hardcoded 'Result' identifier for all functions is a big advantage. But you are still using the function names to set the result values I suppose. So during this clean design designing we need to find a compromise between 2 approaches. Having an implicit result variable or Self variable is something completely different than having the knowledge of a class and scanning its function names and assign a function to a certain name. The first is defined by the compiler, the second is declared by you, the code writer. for example, would you argue if iterator will be any container type: object/class with the next declaration: TMyIterator = object public function StepNext: Boolean; property TheCurrentValue: Integer; iterator MoveNext = StepNext; iterator Current = TheCurrentValue; end; When 'iterator MoveNext' or 'iterator Current' are not defined then compiler uses default hardcoded identifiers 'MoveNext' and 'Current'. This is very like to how you can bind interface methods to the class methods if they are differ. Again, here you mix names and functionality. Compare it to a default propery, you declare it as: property Foo[index:integer]: String read GetFoo; default; and not as property Default[index:integer]: String read GetFoo; Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Thu, Oct 22, 2009 at 01:44, Michael Van Canneyt wrote: > What about > > function StepNext: Boolean; iterator 'movenext'; > property TheCurrentValue: Integer; iterator 'current'; You beat me by two minutes ;-) > function StepNext: Boolean; iterator nextvalue; > property TheCurrentValue: Integer; iterator currentvalue; I do not care much, but putting names in quotes may slightly simplify parser, IMO. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Thu, Oct 22, 2009 at 01:15, Michael Van Canneyt wrote: >> On Tue, Oct 20, 2009 at 20:25, Alexander Klenin wrote: >>> This is because the while you provided is not equivalent to the for loop >>> above. >>> The correct translation would be: >>> var >>> it: TSomethingIterator; >>> ... >>> it := SomeClass.Iterator; >>> try >>> while it.HaveValue do >>> it.NextValue.Something; >>> finally >>> it.Free; >>> end; >>> >>> Now, that is quite e few keystrokes to save, not to mention that >>> if item value is used more than once in the loop, SomeClass.NextValue >>> must be >>> stored in a variable, further bloating code. > > The above is only for classes. No-one said that the iterator must be a > class (e.g. objects are stored on the stack), so it can be reduced to: > > var > it: TSomethingIterator; > > it := SomeClass.Iterator; > while it.HaveValue do > it.NextValue.Something; I agree that _allowing_ iterators to be "plain" objects is useful, in particular as an optimization technique (and Delphi supports that). However, I am against _requiring_ that. Classes is an important feature of Delphi language, and I see no reason to arbitrarily forbid iterators to be class objects. Nevertheless, using "plain" objects does not make any difference in the replacement code size, since plain objects have destructors too. Unless you go C++ way and guarantee the calling of destructor for local objects at the end of the block, try..finally block is still required. > My only worry now is to make sure that if they are implemented, that we make > the design as clean as possible: e.g. No hardcoded dependencies on class or > interface names. As I already argued in this thread, such dependencies may be considered the distinguishing feature of the current Pascal language, so avoiding them at this stage is strange indeed. Still, how about this proposal then: 1) In FPC mode, introduce 'iterator' attribute to the class functions, like this: type TMyIterator = class // or object function GetNext: Boolean; iterator 'MoveNext'; function CurrentValue: TMyType; iterator 'Current'; funtcion Index: Integer; iterator 'CurrentIndex'; end; 2) In FPC mode, require that in "for a in c do" loop, c have to be the iterator, not the container: for t in Tree.InOrderIterator for ch in Chars(MyString) do for a in Elements(MyArray) do where Chars is a normal function defined in RTL, and Elements is built-in half-magic function similar to SetLength. 3) In Delphi mode, additionally auto-decorate each function with 'magic' name with corresponding 'iterator' attribute 4) In Delphi mode, if non-iterator is a second argument of "for a in c", try to call function with 'magic' name GetEnumerator to get the default iterator. Note that this design gets rid of the noting of "default" iterator in FPC mode. If wanted, it can be restored by introducing something like "operator iterator" (aka "operator GetEnumerator" in the current wiki proposal). -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Wed, 21 Oct 2009, Paul Ishenin wrote: Michael Van Canneyt wrote: My only worry now is to make sure that if they are implemented, that we make the design as clean as possible: e.g. No hardcoded dependencies on class or interface names. We need to count the pros and contras first regards hardcoded names and maybe 'hard coded' code. For example for me the hardcoded 'Result' identifier for all functions is a big advantage. But you are still using the function names to set the result values I suppose. So during this clean design designing we need to find a compromise between 2 approaches. for example, would you argue if iterator will be any container type: object/class with the next declaration: TMyIterator = object public function StepNext: Boolean; property TheCurrentValue: Integer; iterator MoveNext = StepNext; iterator Current = TheCurrentValue; end; When 'iterator MoveNext' or 'iterator Current' are not defined then compiler uses default hardcoded identifiers 'MoveNext' and 'Current'. This is very like to how you can bind interface methods to the class methods if they are differ. Hm. I like this direction of thinking, yes... What about function StepNext: Boolean; iterator 'movenext'; property TheCurrentValue: Integer; iterator 'current'; or better yet, because it is more strict: function StepNext: Boolean; iterator nextvalue; property TheCurrentValue: Integer; iterator currentvalue; In this way, it's more like some extra modifiers. (so like safecall, default, stored and whatnot) It just adds some modifiers, and we're free of hard-coded names. With one of these I could live :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: My only worry now is to make sure that if they are implemented, that we make the design as clean as possible: e.g. No hardcoded dependencies on class or interface names. We need to count the pros and contras first regards hardcoded names and maybe 'hard coded' code. For example for me the hardcoded 'Result' identifier for all functions is a big advantage. But you are still using the function names to set the result values I suppose. So during this clean design designing we need to find a compromise between 2 approaches. for example, would you argue if iterator will be any container type: object/class with the next declaration: TMyIterator = object public function StepNext: Boolean; property TheCurrentValue: Integer; iterator MoveNext = StepNext; iterator Current = TheCurrentValue; end; When 'iterator MoveNext' or 'iterator Current' are not defined then compiler uses default hardcoded identifiers 'MoveNext' and 'Current'. This is very like to how you can bind interface methods to the class methods if they are differ. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
In our previous episode, Michael Van Canneyt said: > >> finally > >>it.Free; > >> end; > >> > >> Now, that is quite e few keystrokes to save, not to mention that > >> if item value is used more than once in the loop, SomeClass.NextValue must > >> be > >> stored in a variable, further bloating code. > > The above is only for classes. No-one said that the iterator must be a > class (e.g. objects are stored on the stack), so it can be reduced to: > > var >it: TSomethingIterator; > >it := SomeClass.Iterator; >while it.HaveValue do > it.NextValue.Something; Lightcontainers does something like this, but uses function syntax based on records. HaveValue and NextValue are inline. One could see such constructs using D2006 methods-in-records syntax though, and afaik I have even seen it in the Delphi fora. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Thu, 22 Oct 2009, Alexander Klenin wrote: I understand what this thread is very long and hard to follow. However, could you please at least read direct the answers to your mails: On Tue, Oct 20, 2009 at 20:25, Alexander Klenin wrote: On Tue, Oct 20, 2009 at 20:09, Michael Van Canneyt wrote: But I really don't see the advantage of being able to type For F in Someclass.Iterator do F.Something over While SomeClass.HaveValue do SomeClasss.NextValue.Something; It's not clearer, at most it saves you a couple of keystrokes. This is because the while you provided is not equivalent to the for loop above. The correct translation would be: var it: TSomethingIterator; ... it := SomeClass.Iterator; try while it.HaveValue do it.NextValue.Something; finally it.Free; end; Now, that is quite e few keystrokes to save, not to mention that if item value is used more than once in the loop, SomeClass.NextValue must be stored in a variable, further bloating code. The above is only for classes. No-one said that the iterator must be a class (e.g. objects are stored on the stack), so it can be reduced to: var it: TSomethingIterator; it := SomeClass.Iterator; while it.HaveValue do it.NextValue.Something; On Thu, Oct 22, 2009 at 00:26, Michael Van Canneyt wrote: When there is a big difference between the following goto and the while loop it is supposed to be equal to: :jumphere; If Something(F) then begin F.SomeThingElse; Goto jumphere; end; Here you need quite a few more lines and even an extra label definition, and I don't think anyone will dispute that the while loop is more readable... The main advantage of "while" as compared to "if + goto" is not the code size (there are times when using "goto" leads to shorter code), but in the fact that it represents a more structured approach to coding, reducing a probability of mistakes and easing code maintenance. This is the main argument in favor of "for..in" as compared to "try + while + manual iterator calling". If the try/finally is not needed (see above), then your argument is almost void, and IMHO not worth the effort. Let's be serious: it should be clear that I am not a fan of iterators - just like I think generics is a waste of time - but it looks like they will be implemented, since there seems to be quite some momentum built up in favour of them. Just as it was for generics. My only worry now is to make sure that if they are implemented, that we make the design as clean as possible: e.g. No hardcoded dependencies on class or interface names. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On 21 Oct 2009, at 14:55, Marco van de Voort wrote: That goes for the language feature maybe. The point is to make it worthwhile, and used, it has to be integrated into everything. Which, as that would introduce Delphi incompatibilities probably won't. Just like generics that still consist mostly out of FGL. Generics still don't work 100%, so it's normal that they are not widely used. I also don't don't have a problem with a language feature that's available but not widely used, as long as it doesn't complicate compiler development/maintenance too much. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Thu, Oct 22, 2009 at 00:26, Michael Van Canneyt wrote: >> I beg to disagree.This is completely backwards -- like saying that "while" >> loop is an >> ugly hack to save some typing of "goto" operators. >> Iterators and foreach loops are very important tools of structured coding. >> The fact that "for..in" may be expressed in terms of lower-level >> primitives >> does not decrease its importance, just like existence of "goto" does >> not decrease the importance of "while". > > Well, I think you can't compare the two cases. > > I see little gain in changing > > while Something(f) do > F.Somethingelse > > to > > For f in Something do > F.SomethingElse > > The number of lines is equal, the amount of typed characters also is equal. > It's not more readable, either, IMHO. I understand what this thread is very long and hard to follow. However, could you please at least read direct the answers to your mails: On Tue, Oct 20, 2009 at 20:25, Alexander Klenin wrote: > On Tue, Oct 20, 2009 at 20:09, Michael Van Canneyt > wrote: >> But I really don't see the advantage of being able to type >> >> For F in Someclass.Iterator do >>F.Something >> >> over >> >> While SomeClass.HaveValue do >>SomeClasss.NextValue.Something; >> >> It's not clearer, at most it saves you a couple of keystrokes. > > This is because the while you provided is not equivalent to the for loop > above. > The correct translation would be: > var > it: TSomethingIterator; > ... > it := SomeClass.Iterator; > try >while it.HaveValue do > it.NextValue.Something; > finally >it.Free; > end; > > Now, that is quite e few keystrokes to save, not to mention that > if item value is used more than once in the loop, SomeClass.NextValue must be > stored in a variable, further bloating code. There is another thing: On Thu, Oct 22, 2009 at 00:26, Michael Van Canneyt wrote: > When there is a big difference between the following goto and the while loop > it is supposed to be equal to: > > :jumphere; > If Something(F) then >begin >F.SomeThingElse; >Goto jumphere; >end; > > Here you need quite a few more lines and even an extra label definition, and > I don't think anyone will dispute that the while loop is more readable... The main advantage of "while" as compared to "if + goto" is not the code size (there are times when using "goto" leads to shorter code), but in the fact that it represents a more structured approach to coding, reducing a probability of mistakes and easing code maintenance. This is the main argument in favor of "for..in" as compared to "try + while + manual iterator calling". -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: This is all just nitpicking. Iterators as a language construct are a very ugly hack to save some typing, no matter how you turn it. Nice maybe for languages with dynamic typing and so on, but really not on it's place in Pascal. Ok. There is not a problem to make this feature available only for the delphi mode. Moreover it is much easier to implement them without all that extensions. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: I see little gain in changing while Something(f) do F.Somethingelse This is not quite equal, it's more like: Start(f); while not Last(f) do F.DoWork; In your case, the function 'Something' must know about a generic F. There are also recursive state problems to be thought about. I guess this is why in the STL an iterator is a separate object on the local stack, but able to iterate through (another) object of the defined type. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Wed, 21 Oct 2009, Alexander Klenin wrote: On Wed, Oct 21, 2009 at 23:15, Michael Van Canneyt wrote: This is all just nitpicking. Iterators as a language construct are a very ugly hack to save some typing, no matter how you turn it. Nice maybe for languages with dynamic typing and so on, but really not on it's place in Pascal. I beg to disagree.This is completely backwards -- like saying that "while" loop is an ugly hack to save some typing of "goto" operators. Iterators and foreach loops are very important tools of structured coding. The fact that "for..in" may be expressed in terms of lower-level primitives does not decrease its importance, just like existence of "goto" does not decrease the importance of "while". Well, I think you can't compare the two cases. I see little gain in changing while Something(f) do F.Somethingelse to For f in Something do F.SomethingElse The number of lines is equal, the amount of typed characters also is equal. It's not more readable, either, IMHO. When there is a big difference between the following goto and the while loop it is supposed to be equal to: :jumphere; If Something(F) then begin F.SomeThingElse; Goto jumphere; end; Here you need quite a few more lines and even an extra label definition, and I don't think anyone will dispute that the while loop is more readable... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Alexander Klenin пишет: On Wed, Oct 21, 2009 at 23:15, Michael Van Canneyt wrote: This is all just nitpicking. Iterators as a language construct are a very ugly hack to save some typing, no matter how you turn it. Nice maybe for languages with dynamic typing and so on, but really not on it's place in Pascal. I beg to disagree.This is completely backwards -- like saying that "while" loop is an ugly hack to save some typing of "goto" operators. Iterators and foreach loops are very important tools of structured coding. The fact that "for..in" may be expressed in terms of lower-level primitives does not decrease its importance, just like existence of "goto" does not decrease the importance of "while". One can always say vice versa, that 'goto' is an ugly hack and 'while' is the solution. In general, the more I read the discussion, the more I agree with Michael. We should actually discuss: 1) What is the problem we need to solve 2) What existing solutions already exist and can be used 3) What are the advantages and downsides of each existing solution 4) And after that, we could come up to a design of the new feature. Instead, the discussion is almost ultimately about how to modify the language. The strategic view of the situation is also very desirable. For example, things can change considerably once we have generics are completed, and maybe there's simply no need trying to fit the iterators into today's state. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
In our previous episode, Jonas Maebe said: > > > I've a bit doubts, even aside from any direct opinion on the feature > > itself, > > to add functionality to emulate certain features from other > > language's very > > extensive libraries (like Java/.NET/Boost), since the development of > > the last > > very major feature (and its use), generics has stalled. > > You can always let development occur in a branch (such as with Paul's > changes currently) and only merge to trunk once it's more or less > finished. That goes for the language feature maybe. The point is to make it worthwhile, and used, it has to be integrated into everything. Which, as that would introduce Delphi incompatibilities probably won't. Just like generics that still consist mostly out of FGL. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Wed, Oct 21, 2009 at 23:15, Michael Van Canneyt wrote: > This is all just nitpicking. Iterators as a language construct are a very ugly > hack to save some typing, no matter how you turn it. Nice maybe for > languages with dynamic typing and so on, but really not on it's place in > Pascal. I beg to disagree.This is completely backwards -- like saying that "while" loop is an ugly hack to save some typing of "goto" operators. Iterators and foreach loops are very important tools of structured coding. The fact that "for..in" may be expressed in terms of lower-level primitives does not decrease its importance, just like existence of "goto" does not decrease the importance of "while". -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On 21 Oct 2009, at 14:23, Marco van de Voort wrote: I've a bit doubts, even aside from any direct opinion on the feature itself, to add functionality to emulate certain features from other language's very extensive libraries (like Java/.NET/Boost), since the development of the last very major feature (and its use), generics has stalled. You can always let development occur in a branch (such as with Paul's changes currently) and only merge to trunk once it's more or less finished. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
In our previous episode, Michael Van Canneyt said: > > > > and then tag methods as so? I think though, that the original suggestion > > would work if very well documented or allowing for additional tags somehow? > > > > MyIterator = Iterator(TSomeResultType, Func1::Next, Func2::Prior); > > Nono, A::B is very unpascalish. The location uniquely determines whatever > you need to make the iterator work. I've a bit doubts, even aside from any direct opinion on the feature itself, to add functionality to emulate certain features from other language's very extensive libraries (like Java/.NET/Boost), since the development of the last very major feature (and its use), generics has stalled. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Wed, 21 Oct 2009, Micha Nelissen wrote: Michael Van Canneyt wrote: On Wed, 21 Oct 2009, Micha Nelissen wrote: So the place in this list determines its function? Yes. Just like in an operator... Hmm that's not comparable, for operators it's much more intuitive what to expect as the context is forced, Result := ; A loop also has a 'forced' context of 3 expressions: for i:=expr1 to expr2 do begin // Implicit I:=I+1; end; C makes this even more explicit. This is all just nitpicking. Iterators as a language construct are a very ugly hack to save some typing, no matter how you turn it. Nice maybe for languages with dynamic typing and so on, but really not on it's place in Pascal. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: On Wed, 21 Oct 2009, Micha Nelissen wrote: So the place in this list determines its function? Yes. Just like in an operator... Hmm that's not comparable, for operators it's much more intuitive what to expect as the context is forced, Result := ; Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Wed, 21 Oct 2009, Matt Emson wrote:
Micha Nelissen wrote:
Michael Van Canneyt wrote:
Because with something like
Type
MyIterator = Iterator(TSomeResultType,Func1,Func2,Func3);
So the place in this list determines its function?
The syntax is nice and simple, but I would have to agree. Maybe a two step
would be better? Like with converting an enum to a set?
type
MyIterator = Iterator of TSomeResultType;
MyIteratiorDefinition = class(MyIterator) //class might be another keyword
iteration Func1; MoveNext;
iteration Func1; MovePrior;
{etc}
end;
and then tag methods as so? I think though, that the original suggestion
would work if very well documented or allowing for additional tags somehow?
MyIterator = Iterator(TSomeResultType, Func1::Next, Func2::Prior);
Nono, A::B is very unpascalish. The location uniquely determines whatever
you need to make the iterator work.
Just like in operators:
operator + (A : Real; B TSomeRecord) : Z : TSomeRecord;
A,B, and Z have fixed positions and meanings. Only the names vary.
The list could also then be variable. If it isn't variable with default
implementations for missing members, I don't see the reason why the method
names can't be fixed - or am I missing something obvious? Having a fixed list
may well be confusing should it ever need to be expanded or adapted.
1. The whole point of the exercise is to avoid fixed class or method names.
2. You need only 2 or 3 methods. A for loop in C also has 3 "fields" or
"statements" or wwhatever, and the location determines univocally
what it means.
It's pascal. If we really must introduce iterators - I still think they are
unnecessary bloat - Let's at least keep it simple and clean and similar to
existing features.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Wed, 21 Oct 2009, Micha Nelissen wrote: Michael Van Canneyt wrote: Because with something like Type MyIterator = Iterator(TSomeResultType,Func1,Func2,Func3); So the place in this list determines its function? Yes. Just like in an operator... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Micha Nelissen wrote:
Michael Van Canneyt wrote:
Because with something like
Type
MyIterator = Iterator(TSomeResultType,Func1,Func2,Func3);
So the place in this list determines its function?
The syntax is nice and simple, but I would have to agree. Maybe a two
step would be better? Like with converting an enum to a set?
type
MyIterator = Iterator of TSomeResultType;
MyIteratiorDefinition = class(MyIterator) //class might be another keyword
iteration Func1; MoveNext;
iteration Func1; MovePrior;
{etc}
end;
and then tag methods as so? I think though, that the original
suggestion would work if very well documented or allowing for additional
tags somehow?
MyIterator = Iterator(TSomeResultType, Func1::Next, Func2::Prior);
The list could also then be variable. If it isn't variable with default
implementations for missing members, I don't see the reason why the
method names can't be fixed - or am I missing something obvious? Having
a fixed list may well be confusing should it ever need to be expanded or
adapted.
M
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: Because with something like Type MyIterator = Iterator(TSomeResultType,Func1,Func2,Func3); So the place in this list determines its function? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test
fpc...@silvermono.co.za wrote: Hi, Just subscribed, testing system. Welcome Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Wed, 21 Oct 2009, Micha Nelissen wrote: Michael Van Canneyt wrote: Ideally, the compiler has no knowledge at all of specific classes, and a new keyword such as Iterator (or whatever) helps in ensuring that the compiler is not contaminated with knowledge of specific classes or methods. I'm not sure how things are helped by "slapping" a keyword onto it? If we call the thing a "class" then it's evil, but if it's called an "iterator" which is actually the exact same thing as a class, it's fine? Correct me if wrong. Because with something like Type MyIterator = Iterator(TSomeResultType,Func1,Func2,Func3); Function MyIterator.Func1 : TSomeResultType; begin end; Etc. You're free to choose the names of the functions, so nothing has to be hardcoded in the compiler. It's a bit like operators, where you can also choose the names of the operands. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Test
Hi, Just subscribed, testing system. Regards, Nino ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: LAMBDA
Jeff Wormsley wrote: > Wow, talk about unreadable code... > In fact I did not ever try to understand this. I just happened to know about Lambda in Prism and wanted to let the forum share that. > I'm all for saving typing, but not at the expense of readability. Agreed. > This > reminds me of C's oddball ? operator. In fact I think that the ? operator in C is easily readable (But of course in C you easily can create unreadable code by e.g. doing assignments in if-clauses. if (a=b) a=1; which happens to translate in Pascal as: a:=b; if a<>0 then a:=1; -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: Ideally, the compiler has no knowledge at all of specific classes, and a new keyword such as Iterator (or whatever) helps in ensuring that the compiler is not contaminated with knowledge of specific classes or methods. I'm not sure how things are helped by "slapping" a keyword onto it? If we call the thing a "class" then it's evil, but if it's called an "iterator" which is actually the exact same thing as a class, it's fine? Correct me if wrong. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: > Ideally, the compiler has no knowledge at all of specific classes, and a > new > keyword such as Iterator (or whatever) helps in ensuring that the compiler > is not contaminated with knowledge of specific classes or methods. That is a very conservative (but of course viable) view on a language. Plain old C is clean in that way, but I suppose even C++ (which I never use) is not. I have the impression that modern implementation of languages increasingly do provide "syntax sugar" to improve the usability of certain library functions. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Vinzent Höfler wrote: Von: Micha Nelissen That's why I suggested the use of 'const functions' in other message in this thread. Yes, I read that later on. Is that implemented in FPC? I don't think so; but I think it would be a useful part of the iterator proposal. The iterator case really gives it some strength. If not used by other features it may seem more like a "OO-purity" thing (although that is not per definition bad) ;-). Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Wed, 21 Oct 2009, Paul Ishenin wrote: Sergei Gorelkin wrote: The question is, what advantage all this specific syntax could give over simple searching the methods by name? Some people need less compiler magic, some does not care. New directive can reduce the magic level :) Btw, we use similar compiler magic every day. Just think of: 1. functions which all have special 'Result' variable :) 2. message methods which calls 'TObject.DefaultHandler' when you call inherited inside. 3. tobject methods related to interfaces I suspect there are more examples. In all the listed examples compiler searches for the special identifier. Therefore GetEnumerator identifier looks as very native solution for pascal. Note that all these cases are introduced by Borland, and they are not exactly an example of clean design. They are is what I referred to when I said that the compiler already relies too much on TObject/IInterface methods. Ideally, the compiler has no knowledge at all of specific classes, and a new keyword such as Iterator (or whatever) helps in ensuring that the compiler is not contaminated with knowledge of specific classes or methods. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
