I use Perl a lot so the new for..in loops in Delphi caught my eye:

program ForIn;
type TStringArray = array of String;
procedure Demo1(const List: TStringArray);
var S: String;
begin
  for S in List do writeln(S);
end;
var sa: TStringArray;
begin
  Demo1(sa);
end.

fpc 2.0.0 doesn't compile this... are "for..in" loops in a newer version or will they be sometime soon? Here is a little blurb about it from Google's cache:

http://66.102.7.104/search?q=cache:jti97cSprR0J:homepages.borland.com/dthorpe/blog/delphi/2004_08_01_archive.php%3Fshow_id%3D109211211041479238+freepascal+%22for+in%22+loop&hl=en

I'm still using Delphi 7... so it's not clear if this is already available or in the new Delphi 2006 available next year...

-Alan

fpc 2.0.0 doesn't compile this... are "for..in" loops in a newer version or will they be sometime soon? Here is a little blurb about

FPC will never support this, AFAIK. It doesn't really add anything new, it just shortens the code somewhat. Only in toy examples is it nice, in practice it doesn't really matter. We should try to keep the language as small and clean as possible.

Micha

Ok this was too quick; probably FPC will support it if a lot of code appears that is using it, but that's not the coming year or the one after, I guess.

Micha

the new for..in loops in Delphi caught my eye fpc 2.0.0 doesn't compile this... are "for..in" loops in a newer version or will they be sometime soon?

I believe this was discussed at great length back in February, but I'm not sure what the final verdict was:

http://lists.freepascal.org/lists/fpc-devel/2005-February/

( It's in the thread named "Modernising Pascal" )

- Jeff

If somebody shows me how I can walk e.g. a linked list with foreach ...
in ... do with the same speed as with p:=p^.next; then we'll add it :p

However, we're currently concentrating our efforts regarding language features on stuff which gives you a real gain like templates and language supported multithreading, not some useless thing invented by Borland to have something new in D2005.

Note that part of this is quite elegant on .NET since basically is an object, and so everything can support some iterator interface, and the JIT can optimize a lot overhead away.

It doesn't work that way in native, and needs lots of expensive helpers, iow supporting it is a hack. Note that Perl is also OOP to a higher degree with JIT.

This is the problem with a lot of new Delphi.NET syntax. It might be backportable to native, but it feels "odd". The .NET generics have similar issues.

I was also wondering HOW it would be done, but I just assumed that everything was easy for you guys :)

Would it be hard for the compiler to try to automatically convert this new construct into an equivalent older one? .. So when it finds

for S in ArrayOfInteger do ...

it silently converts it to

for i := 0 to {Count} do
  begin
    S := ArrayOfInteger[i];
    ...

? I don't know enough about the internals to know how hard it is to know the limits of the array and the type...

I'd have to agree though, that this isn't a big deal one way or the other. One note: The D2006 marketing materials (AFAICT) suggest that this isn't just a .NET thing.

-Alan

It would require special tailored code for each type. (normal arrays, open arrays, dynarrays, pchars (length) etc etc) Moreover, what's the point?

I'd have to agree though, that this isn't a big deal one way or the other. One note: The D2006 marketing materials (AFAICT) suggest that this isn't just a .NET thing.

Nobody uses it unless they are backporting from .NET. Simply because the hordes of win32 Delphi programmers still use D6 and D7.

Nobody uses it unless they are backporting from .NET. Simply because the hordes of win32 Delphi programmers still use D6 and D7.

And even greater is the horde of programmers still using Visual Studio 6.0.

tsc tsc tsc .... I just can´t figure out why some developers of IDEs think that .NET should substitute all existing developing technologies.

For me it´s very good. While they develop their ultra-slow programs that require a really heavy framework, I can develop my fast, small and stable programs =)

All the arrays would be handled the same. The compiler can just generate low() and high() nodes, and those will automatically do the right thing.

Since a pchar is not an array but a pointer to a (possibly null- terminated) array, whether or not that construct supports pchars would be a separate decision.

Jonas

Micha Nelissen said:

FPC will never support this, AFAIK. It doesn't really add anything new, it just shortens the code somewhat. Only in toy examples is it nice,

Could you expand this answer to cover the reasons why people might use Pascal rather than assembly language? Your argument seems to advocate using the lowest level language available...

I'm a big fan of compact code and language features that promote it. Give me "StringList.SaveToFile()" any day over the laborious code that starts "var F:TextFile;"

Moz

foreach ... in ... do adds no additional abstraction layer. I consider foreach usefull if it allows to create own iterators which are as fast as walking a linked list with p:=p^.next; Especially since it then allows e.g. to write iterators with data prefetching.

Foreach makes even the intuitive understanding of the code harder because it misses the information if the iterator is random or ordered. I think when I'll ever implement foeach ... in ... I'll translate it to for ...:=high... downto low... do I guess a lot of code while crash because people think foreach is increasing ;)

I'm a big fan of compact code and language features that promote it.

Every new language features makes it harder to learn a language and to read the code.

Give me "StringList.SaveToFile()" any day over the laborious code that starts "var F:TextFile;"

That already ambigious, the method should be called StringList.SaveToTextFile()

(
A.S.
These don't have the same properties. Using basic I/O one can work with textfiles larger than the (virtual) memory. With stringlist there always must be full in memory loading.
Moreover stringlists get painfully slow over a few ten thousand lines. )

However stringlist _adds_ something. You can really do stuff in a few lines that takes tons of manual coding.

FOR IN on the other hand saves only two lines of plain typing, something that could even be compensated with a small Lazarus codetools "generate construct" macro.

Moreover stringlist doesn't need compiler support to do it.

foreach ... in ... do adds no additional abstraction layer. I consider foreach usefull if it allows to create own iterators which are as fast as walking a linked list with p:=p^.next; Especially since it then allows e.g. to write iterators with data prefetching.

Just my two cents:

For-in loops is standard part of Delphi-2006 pascal language. (Not only for .NET, it is for Win32 too!)

I think, if Freepascal wish to stay Delphi compatible, then is good idea to implement this features too. Look to next Pascal language enhancements in Delphi-2006... (like operator overloads or class variables...)

You're kidding, aren't you?

I'm a big fan of compact code and language features that promote it. Give me "StringList.SaveToFile()" any day over the laborious code that starts "var F:TextFile;"

I agree with that principally, but stringlists *are* really slow on thousands of lines (been there, done that).

But in the meantime I'm preferring fpc getting ported to more platforms over having Microsoft's syntactic sugar implemented. This sucks of development power and is only of interest for a few people. Having fpc on Mac or ARM would never happen if anyone were running after Borland or Microsoft.

If you really need some new statement types you can

- make patches for the compiler
- or use a preprocessor
- or use Smalltalk/Java/Eiffel/Python/Ruby (if you like Pascal better then ASM)

If you'd ask me: My wish would be to see fpc compiling programmes for the BlackFin-CPUs and for the ECOS2 operating system, can this be implemented, please? ;)

Marc

... which has fpc for years :)

I don't see it as a high priority. It takes some minutes to change the code implemented with a for-in loop if it's needed. What does Free Pascal need is a good type safe containers library and probably this is the reason why the compiler team is concentrated on the implementation of generics: provide strong type safety on containers in the spirit of pascal.
And using a containers library you can allways use iterators, it's not a language feature.
I'm happy that the compiler guys do not waste their precious time over sintactic sugar issues.

Look to next Pascal language enhancements in Delphi-2006... (like operator overloads or class variables...)

we already have them in free pascal for a couple of years iirc and I've never used them.

Ciao,
Dean

That's because they are quite limited if you have dynamic, non garbage collected objects.

For .NET that is no problem, since the objects are GCed, and for C++ they are static.

But for native Delphi, there is no good solution to do OO without a thick helper layer.

I didn't know that. How do I declare a class variable in fpc?

like this?
type
   MyClass = class(TComponent)
   private
     class FClassVar: integer;
     FFieldVar: integer;
   end;

Vincent.

Why? Use them with interfaces if you need garbage collection and it works perfectly.

Because that is not the same. A fully GC language can optimize a lot of overhead away. GC duck-taped on a native language is not pretty useful. See the only big experiment that uses interfaces this way: decal and its abmyssal performance.

One can discuss if it comes back to native level as the .NET and Java advocatist claim ( I don't), but no matter what you think about that subject, native-with-gc is worse.

With C++ you end also with ref. counted types in the best case. You can't do it better. The reason why interfaces are used that those are the only automated types which can be used to do everything. GC is something completely different. I don't consider interfaces or ansistring garbage collected.

the only big experiment that uses interfaces this way: decal and its abmyssal performance.

That's something completely different. Decal's performance is so bad because it has no templates.

I remember I've successfully used them with refcounted interfaces in a demo see
http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/fcl/fpcunit/exampletests/money.pp

but still doing
a + b or a.add(b) it's not that different and maybe the second is clearer;

Ciao, Dean

Sure it can be implemented, and we are anxiously awaiting your patches.

So the number of users of fpc is extended by two? three at most? :-)

Mark

FClassVar:integer;static;

And compile with -St

Peter

Florian told me the right syntax.
I used {$static on}.

See
http://www.freepascal.org/bugs/showrec.php3?ID=4528 and
http://www.freepascal.org/bugs/showrec.php3?ID=4529

Vincent.