Re: [fpc-pascal] Delphi's anonymous functions in Free Pascal

2012-10-28 Thread 印場 乃亜

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

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


Re: [fpc-pascal] Delphi's anonymous functions in Free Pascal

2012-10-28 Thread 印場 乃亜
Hi,
On 2012/08/31, at 2:51, Jürgen Hestermann juergen.hesterm...@gmx.de 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 

Re: [fpc-pascal] Delphi's anonymous functions in Free Pascal

2011-10-22 Thread Juha Manninen
2011/10/22 Gregory M. Turner g...@malth.us

 Taking these terms in the broadest sense possible, wouldn't we say that OOP
 is mostly a functional development paradigm?

 Not a rhetorical question, I seriously am not sure.

 OP's somewhat idiosyncratic requirement to put all the OOP metadata in a
 separate interface section of your code kind of underlines what I'm talking
 about.  It seems to me that in OOP, whatever we might happen to do
 procedurally, there's a strong declarative odor to everything happening at
 the class/interface level.


Now you are mixing the well-established terms.
Functional programming paradigm is based on lambda calculus. There are no
loop constructs or even variables in normal sense.
There are only functions which return a value without side-effects.

In Object Pascal you must define types in interface, but it doesn't change
the object oriented paradigm anyhow.
In Java or C# you don't have interface definitions but they still have the
same paradigm.

Wikipedia has amazingly much info. See:

http://en.wikipedia.org/wiki/Functional_programming

On the right edge there is a list Programming Paradigms.

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

Re: [fpc-pascal] Delphi's anonymous functions in Free Pascal

2011-10-21 Thread Alexander Shishkin

18.10.2011 0:53, Andrew Pennebaker пишет:

Does Free Pascal have anonymous functions that you can pass around, e.g.
to a sort(compare : function, arr : array) function?



anonymous functions = closures = lambdas are part of functional 
paradigm. object pascal itself is not functional language.
But there is modern trend to design multiparadigm languages (usually OO 
+ functional + imperative).
Delphi followed this trend. So the question is: should freepascal follow 
this trend too?




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


Re: [fpc-pascal] Delphi's anonymous functions in Free Pascal

2011-10-21 Thread Gregory M. Turner
- Original Message -
 18.10.2011 0:53, Andrew Pennebaker пишет:
  Does Free Pascal have anonymous functions that you can pass around,
  e.g.
  to a sort(compare : function, arr : array) function?
 

 anonymous functions = closures = lambdas are part of functional
 paradigm. object pascal itself is not functional language.
 But there is modern trend to design multiparadigm languages (usually
 OO
 + functional + imperative).
 Delphi followed this trend. So the question is: should freepascal
 follow
 this trend too?

Taking these terms in the broadest sense possible, wouldn't we say that OOP is 
mostly a functional development paradigm?

Not a rhetorical question, I seriously am not sure.

OP's somewhat idiosyncratic requirement to put all the OOP metadata in a 
separate interface section of your code kind of underlines what I'm talking 
about.  It seems to me that in OOP, whatever we might happen to do 
procedurally, there's a strong declarative odor to everything happening at the 
class/interface level.

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


Re: [fpc-pascal] Delphi's anonymous functions in Free Pascal

2011-10-19 Thread Alexander Shishkin

19.10.2011 12:16, Sven Barth пишет:


E.g.

TIntegerFunc = reference to function: Integer;

procedure SomeOtherProc(aFunc: TIntegerFunc);
...

procedure Foo;
var
x: Integer;
begin
x := 42;
SomeOtherProc(function: Integer; begin Result := x; end;);
end;

I haven't tested that, but from the description that should work.

The FPC equivalent should be (not tested as well):

type
TIntegerFunc = function: Integer is nested;

procedure SomeOtherProc(aFunc: TIntegerFunc);
...

procedure Foo;
var
x: Integer;

function ReturnX: Integer;
begin
Result := x;
end;

begin
x := 42;
SomeOtherProc(@ReturnX);
end;

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




But _real_ functional equivalent of Delphi's function reference if 
COM-interface based functor.

F.e.
TMyFuction = reference to function: Integer; 
and
IMyFunction = interface
function Invoke:Integer;
end;




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


Re: [fpc-pascal] Delphi's anonymous functions in Free Pascal

2011-10-18 Thread Sven Barth

Am 17.10.2011 22:53, schrieb Andrew Pennebaker:

Does Free Pascal have anonymous functions that you can pass around, e.g.
to a sort(compare : function, arr : array) function?

If not, does anyone know any hacks to accomplish this?


No, FPC does not support this currently and I know no one who plans to 
support it in the near future.


A similiar feature available in the upcoming 2.6 and in trunk are 
nested function references. I wrote about that some days ago in this 
mail: http://www.hu.freepascal.org/lists/fpc-pascal/2011-October/030460.html


Regards,
Sven

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