Delphi's anonymous functions in Free Pascal

classic Classic list List threaded Threaded
125 messages Options
1 ... 4567
Reply | Threaded
Open this post in threaded view
|

Re: Delphi's anonymous functions in Free Pascal

Sven Barth-2
On 30.08.2012 11:03, Arioch wrote:
> But afterall i am quitting on that. Since FPC are lacking closures i am sure
> here are mostly people who personally dislike them. I wanted to document why
> closures are good and do matter. Hopefully i did it to the extent i was able
> to. Surely i would not be able to convince you infinite time. So the rest of
> arguments would be questions of personal tastes and it would bring nothing
> but flamewar.

The closures (or anonymous functions as they are called in Delphi) are
missing, because none of the developers has them on the important slots
of the todo lists. So as long as nobody comes and implements them then
they are not going to be implemented (at least in the near future). One
member of the community stepped up some months ago to implement them (he
even has a branch in SVN), but he didn't go far. I don't know whether it
was his motivation or his time or his knowledge that left him...

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Delphi's anonymous functions in Free Pascal

Jürgen Hestermann
In reply to this post by Ralf A. Quint
Am 2012-08-30 18:29, schrieb Ralf A. Quint:
 > Pascal has evolved since Wirth's original design back in the 70s

This is true. But there are two aspects of the Pascal extensions of the last years (decades) that contradict with what I would call the "spirit of Pascal":

1.) Many "extensions" add to the learning curve of newbies (where will Pascal be in 10 or 20 years and how long does it take a pupil to learn it?). Adding extensions over and over again without much thinking will ruin the language some day because nobody will try this bloated software anymore. I have programmed with Turbo Pascal quite a lot in the 80s and 90s but when I read about the "recently" added concepts I don't understand a word (and I also never missed them!). It seems that these extensions cannot even be easily explained because the concepts are very obscure and require sophisticated knowledge about the compiler to understand them. Extensions in the past were very easy to understand and to handle.

2.) Many "extensions" come from other languages and break fundamental (Pascal) laws (as I would call them). For example, to me an identifier *has* to mean the same in all contexts of a program (whether declaration, function parameter, part of an expression, ..). Dynamic arrays violate this by meaning the address of a pointer or the address of the first array element depending on whether they are dereferenced or not. Pointers should be shown as pointers and not obscured. This leads to a very lot of misunderstandings. Borland should have looked for a cleaner solution for such dynamic arrays IMO. But now the sin has been commited and cannot be withdrawn. Nevertheless, no new sins should be added anymore.

The result is that Pascal is no longer that clear and easy to learn (yet powerful) language that it was. Of course, you can still ignore all the extensions that have been added but you cannot understand foreign code anymore (which is often necessary to understand what happens in the compiler or libraries when using them).
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Delphi's anonymous functions in Free Pascal

Marco van de Voort
In reply to this post by Sven Barth-2
In our previous episode, Sven Barth said:
>
> The closures (or anonymous functions as they are called in Delphi) are
> missing, because none of the developers has them on the important slots
> of the todo lists. So as long as nobody comes and implements them then
> they are not going to be implemented (at least in the near future). One
> member of the community stepped up some months ago to implement them (he
> even has a branch in SVN), but he didn't go far. I don't know whether it
> was his motivation or his time or his knowledge that left him...

Besides that, I've seen some question marks about that feature in the
Delphi community too. Specially the predictability of the state that is
actually captured by the anonymous function.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Delphi's anonymous functions in Free Pascal

shiruba2012
In reply to this post by Arioch

Hi,

...

> -----
> This is funny to remember today. ;-)
> When i run BP 7 on 80286 computers, and then compared with size and speed of
> TP 5.5 - i was sure as hell that OOP is for lazy programmers, who cannot
> make code fast and small.
> And i remember comparing speed of Virtual Pascal and contemporary FPC. VP
> bet everything on compilation efficiency. And died.
>

This was sad to me.  I ported the FPC system libraries (All of sysutils,pas, etc.) to VP with the goal of helping it live longer and work better on linux.  The next version of SysUtils for FPC used features VPC didn't have, and I couldn't fake without modifying the compiler.  I have the compiler source (The author made a "Core Team" to work on the compiler, and shared the source code and some bata builds for linux, etc.).  Unfortunately, at that time I was in college, and didn't have time to learn the intricacies of i386 ASM when I was already dealing with MIPS ASM in school!  

The compiler is one solid block of ASM code, and about impossible for anyone but the author to modify, I suspect.  It was perhaps the right design decision at the time, however.  

> But afterall i am quitting on that. Since FPC are lacking closures i am sure
> here are mostly people who personally dislike them. I wanted to document why
> closures are good and do matter. Hopefully i did it to the extent i was able
> to. Surely i would not be able to convince you infinite time. So the rest of
> arguments would be questions of personal tastes and it would bring nothing
> but flamewar.
>
I don't think personal taste should come into it.  As far as I know, one of the missions of FPC is to be an alternative to other Pascal compilers, which means we should strive for feature parity with the popular distributions.  We could go the "Pure" route, but then we would end up with something nearly useless like GPC.  (I tried GPC before around year 2000, and I couldn't even compile Hello World type programs from TP7!)

> Allow me to congratulate you all with Lazarus 1.0 release and thank you with
> good and practical language implementation.
>
Likewise.  I wish I had more time to contribute to this great "product".

> Have a nice TimeOfDay();*)
>

Thank you,
    Noah Silva
>
>
> --
> View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Delphi-s-anonymous-functions-in-Free-Pascal-tp4911527p5711060.html
> Sent from the Free Pascal - General mailing list archive at Nabble.com.
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Delphi's anonymous functions in Free Pascal

shiruba2012
In reply to this post by Jürgen Hestermann
Hi,
On 2012/08/31, at 2:51, Jürgen Hestermann <[hidden email]> wrote:

> Am 2012-08-30 18:29, schrieb Ralf A. Quint:
> > Pascal has evolved since Wirth's original design back in the 70s
>
> This is true. But there are two aspects of the Pascal extensions of the last years (decades) that contradict with what I would call the "spirit of Pascal":
>
> 1.) Many "extensions" add to the learning curve of newbies (where will Pascal be in 10 or 20 years and how long does it take a pupil to learn it?). Adding extensions over and over again without much thinking will ruin the language some day because nobody will try this bloated software anymore. I have programmed with Turbo Pascal quite a lot in the 80s and 90s but when I read about the "recently" added concepts I don't understand a word (and I also never missed them!). It seems that these extensions cannot even be easily explained because the concepts are very obscure and require sophisticated knowledge about the compiler to understand them. Extensions in the past were very easy to understand and to handle.
>
Perhaps, and I agree with you to some extent.  You can pick up Pascal and do something like:

program hello;

begin
  writeln('Hello World');
end;

hit compile, and watch it run - even now.  And that's great, but if you want to write a web browser, or an application server, or a GUI application, you need to do an awful lot of manual work in, f.e. TP7.  The first time I saw TurboVision, I thought "What a monster!", what with all those carrots for dereferencing the old style Objects, etc.  Yet writing something like the TP7 editor without OOP would have been more a of a chore chan learning TurboVision for sure.  

Anyone who says "I just want to save a value in a file" wouldn't want to learn SQL either - but once you have learned SQL, a lot more is possible.  Actually, one of the reasons I like Pascal is because you can do low level things and high-level things in the same language.  Normally I try to do everything high-level, but sometimes we have to do some dirty-work, and we can when needed.  A good example is that LCL and FPC itself is written in Pascal.  (Unlike, say, VB6, which is just  scripting language for components written in C, really).

> 2.) Many "extensions" come from other languages and break fundamental (Pascal) laws (as I would call them). For example, to me an identifier *has* to mean the same in all contexts of a program (whether declaration, function parameter, part of an expression, ..). Dynamic arrays violate this by meaning the address of a pointer or the address of the first array element depending on whether they are dereferenced or not. Pointers should be shown as pointers and not obscured. This leads to a very lot of misunderstandings. Borland should have looked for a cleaner solution for such dynamic arrays IMO. But now the sin has been commited and cannot be withdrawn. Nevertheless, no new sins should be added anymore.
>
Well the extensions usually come because they are useful, and people have demanded them.  If you are only using Pascal, then of course, they may seem like unwanted fluff.  If you have used those features in other languages and then Pascal doesn't have them, then you would feel very limited.  For example, pascal has "With.. Do".  I use this all the time like:

With Object1 do
  begin
    size := 1;
    color := green;
    width := 84;
    Style := stNew;
  end;

In other languages I use, I have to laboriously type;
  Object1.size = 1;
  Object1.color = green;
...

But for example, ABAP programmers who have never used pascal have no idea that they are missing this feature.
On the other hand, it would be super amazingly convenient if Pascal has the database integration that ABAP has, but most people who use FPC have no idea about this feature, so they don't know what they are missing.

The dynamic arrays thing also applies to LongStrings as well, but you should never have to dereference either in normal circumstances.

> The result is that Pascal is no longer that clear and easy to learn (yet powerful) language that it was. Of course, you can still ignore all the extensions that have been added but you cannot understand foreign code anymore (which is often necessary to understand what happens in the compiler or libraries when using them).

Well...  Understanding foreign code is difficult either way.  For example, though, I think understanding foreign code that uses standard features is easier than understanding old foreign code that fakes those features with older pascal versions that lacked a standard way of implementing the functionality.  For example, I have seen:

1. Hand-rolled dynamic array code full of pointer dereferences and malloc() calls.
2. Hand-rolled variant code full of structures with multiple interpretations and typecasting.
3. Hand-rolled generic features, full of typecasting random objects to "Pointer" or "PObject".  (This is very common in Delphi code, since StringLists, etc., can hold "Objects").
4. Hand-rolled OOP functionality with VMT in a record.... (Before OOP was introduced into Pascal).

All of these things are easier to understand if there is a common standard that people use, even if you have to learn that standard first.  For example, I don't consider myself a Java Guru, but for most basic things, there is one standard way of doing it which everyone uses, and I can look up that library to see what's going on.  That's better than trying to figure out a bunch of convoluted code where the program logic is intermixed with the implementation of features that should be in the compiler or (at least) a separate library).  

Either way, when you want to do complicated things, you will need to choose between three options
1. Implement the feature manually in code (if possible)
2. Do without the feature and write your program (if possible, may require much more effort)
3.  Have the feature implemented into the language, so that everyone can use it, and use it in the same way.

If you are only writing simple programs, though, you can of course ignore the extensions in most cases.  I personally ignore a lot of things.  I very rarely use Variants, TStream, etc.  I also prefer to write and execute SQL statements than to use the OOP database features.  On the other hand, some new features I used immediately as they became available because they allow me to do that much less work or stop using TypeCasting (Dynamic Arrays, Long Strings, Generics, etc.)

At any rate, it really comes down to what people want FPC to be:
1. A viable alternative to Delphi and the other compilers and an active language for developers to use.
2. A project to duplicate the antique TP7 compiler on modern hardware for enthusiast programmers.

I am not saying that option 2 is bad, but I think there is a lot of demand for option #1.  Personally, if I couldn't do #1 in Pascal, I would be forced to use Java or Mono for writing complex cross-platform software, so I hope FPC keeps on track.

Thank you,
     Noah Silva

> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
1 ... 4567