Delphi's anonymous functions in Free Pascal

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

Re: Delphi's anonymous functions in Free Pascal

Marco van de Voort
In our previous episode, Martin Schreiber said:
> So probably there are at least two different expectations into FPC which can't
> be fulfilled both: "best general purpose software development environment
> ever" and "100% current Delphi compatibility".

That "current" is added by you. FPC strives to do that of course, but never
had the illusion it was near enough to claim something like that. Not now,
and not in the past.
_______________________________________________
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

Jonas Maebe-2
In reply to this post by Jürgen Hestermann

On 07 Nov 2011, at 18:45, Jürgen Hestermann wrote:

> Jonas Maebe schrieb:
>> That's exactly what he said: you are free to create a fork (= take the FPC source code and do whatever you want with it), and then the currently active FPC developers are also free to take whichever of your patches they consider useful. What's not possible is that other people dictate what you must do with the FPC source code, just like you can't dictate what other people must do.
>>
> This argument is pulled out each time someone suggest things that the main developers don't like. But despite from the work this requires it would result in my own island solution. It cannot be the goal that thousands of people spawn their own Pascal dialect. I don't think that anybody is wanting this. I thought this open source project is about having a *public* Pascal language which can be discussed and argued about. I know that there will be no common sense about each and every topic but it should be possible to say opinions which possibly make others change their mind (or not).

The problem is that the work needs to be done. And once it is done, it needs to be maintained, and must impact other potential work as little as possible. Because of these reasons
a) people who implement stuff have way more influence than people who only voice their opinion about what/how something should be implemented
b) people who have already implemented lots of stuff have more influence than people who have not done that

It's not that longtime developers won't listen to other opinions, but they do have the final say. Without such a dynamic, the project simply cease to exist. After all, without the people who do the work there is nothing at all, not even a project going into a direction that you don't like.

The reason that this argument is always used is simply because that is simply how it is. You can argue that it should be different, but really the only way to do that is to do the work yourself. That may well be an uphill battle if you wish to fundamentally change some things or the development direction of an entire project, in which case starting your own project may be the best option. After all, that would give you the opportunity to demonstrate that your way is actually better and will attract more/better/whatever developers and users, or otherwise will result in something more useful, rather than just arguing that this will be the case and that people should understand that.


Jonas_______________________________________________
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
Jonas Maebe schrieb:
 >>> That's exactly what he said: you are free to create a fork
 >> This argument is pulled out each time someone suggest things that
the main developers don't like.
 > The reason that this argument is always used is simply because that
is simply how it is.

I know that. But still: Why is this argument used like a knee-jerk
reaction as soon as someone writes unliked opinions? That's like saying:
"Stop critisizing me. I don't like this. I am the boss!". If you don't
like to write facts/reasons then don't say anything but using your
thought-terminating cliché over and over again just makes you sound
arrogant.


 > It's not that longtime developers won't listen to other opinions,

But that's what you do when using your standard argument.
_______________________________________________
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

Graeme Geldenhuys-2
In reply to this post by Marco van de Voort
On 7 November 2011 20:41, Marco van de Voort wrote:
>
> That "current" is added by you. FPC strives to do that of course, but never
> had the illusion it was near enough to claim something like that. Not now,
> and not in the past.

So what exactly is the goals of FPC then? And please don't tell me
"delphi compatible" because then you need to tell me which version of
Delphi - and I doubt you can.

As a core developer of FPC can yo please summarize in one or two
sentences the actual goal of FPC - that way we are all on the same
page.


--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
_______________________________________________
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

Florian Klaempfl
In reply to this post by Jürgen Hestermann
Am 08.11.2011 07:20, schrieb Jürgen Hestermann:
> Jonas Maebe schrieb:
>>>> That's exactly what he said: you are free to create a fork
>>> This argument is pulled out each time someone suggest things that the
> main developers don't like.
>> The reason that this argument is always used is simply because that is
> simply how it is.
>
> I know that. But still: Why is this argument used like a knee-jerk
> reaction as soon as someone writes unliked opinions?

The opinion is not unliked but just useless and wastes the time of
people who try to use this mailing list to support others using fpc. If
you want to express opinions again and again without any consequences
like coming up with code just write a blog. You know, "talk is cheap,
show me the code" (Thorvalds).
_______________________________________________
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

Florian Klaempfl
In reply to this post by Graeme Geldenhuys-2
Am 08.11.2011 07:35, schrieb Graeme Geldenhuys:

> On 7 November 2011 20:41, Marco van de Voort wrote:
>>
>> That "current" is added by you. FPC strives to do that of course, but never
>> had the illusion it was near enough to claim something like that. Not now,
>> and not in the past.
>
> So what exactly is the goals of FPC then? And please don't tell me
> "delphi compatible" because then you need to tell me which version of
> Delphi - and I doubt you can.
>
> As a core developer of FPC can yo please summarize in one or two
> sentences the actual goal of FPC - that way we are all on the same
> page.

Let me answer:
Writing an (L)GPL'ed pascal (*) compiler being self hosting.

(*) pascal might be replaced by 'wirthian languages' if someone with a
lot of commitment over years pops up and works on this.
_______________________________________________
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

Graeme Geldenhuys-2
On 8 November 2011 09:23, Florian Klaempfl  wrote:
>
> Let me answer:
> Writing an (L)GPL'ed pascal (*) compiler being self hosting.


>From the man himself. OK good, so now we all know the goal is not one
of "delphi compatible" (that is rather limited only as a side effect -
nice to have), so please all core developers, stop using that as an
excuse to stop other FPC innovation. Over the years I have heard many
features being declined because they will "not be delphi compatible".


--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
_______________________________________________
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

Tomas Hajny-2
On Tue, November 8, 2011 09:01, Graeme Geldenhuys wrote:

> On 8 November 2011 09:23, Florian Klaempfl  wrote:
>>
>> Let me answer:
>> Writing an (L)GPL'ed pascal (*) compiler being self hosting.
>
>
> From the man himself. OK good, so now we all know the goal is not one
> of "delphi compatible" (that is rather limited only as a side effect -
> nice to have), so please all core developers, stop using that as an
> excuse to stop other FPC innovation. Over the years I have heard many
> features being declined because they will "not be delphi compatible".

Examples?

Tomas


_______________________________________________
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

Martin Schreiber-2
In reply to this post by Graeme Geldenhuys-2

On Tuesday 08 November 2011 09.01:03 Graeme Geldenhuys wrote:

> On 8 November 2011 09:23, Florian Klaempfl wrote:

> > Let me answer:

> > Writing an (L)GPL'ed pascal (*) compiler being self hosting.

> >

> >From the man himself. OK good, so now we all know the goal is not one

>

> of "delphi compatible" (that is rather limited only as a side effect -

> nice to have), so please all core developers, stop using that as an

> excuse to stop other FPC innovation. Over the years I have heard many

> features being declined because they will "not be delphi compatible".


I fear the opposite: all Delphi "crap" will be implemented.


Martin


_______________________________________________
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

Graeme Geldenhuys-2
In reply to this post by Tomas Hajny-2
2011/11/8 Tomas Hajny :
>
> Examples?

I can list them all, but I'm not going to waist my time on them again.
Search the mailing list or Mantis.

But to humour you, here is just one of many examples: THelpEvent in
the RTL. I proposed a patch to change it to be more in line with FPC's
goals [being a cross-platform compiler, so requires cross-platform
solutions]. The change was declined because THelpEvent is a direct
copy of Delphi's equivalent, and even worse, is very Windows specific
in its signature. Yes, it's a small and stupid example, but there are
many more like this. Delphi-compatibility seems to trump everything
else (as Martin said).

--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
_______________________________________________
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 Martin Schreiber-2
In our previous episode, Martin Schreiber said:
> > nice to have), so please all core developers, stop using that as an
> > excuse to stop other FPC innovation. Over the years I have heard many
> > features being declined because they will "not be delphi compatible".
>
> I fear the opposite: all Delphi "crap" will be implemented.

Don't worry, there is also room for FPC "crap" ("case string of" e.g.) :-)
_______________________________________________
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

Tomas Hajny-2
In reply to this post by Graeme Geldenhuys-2
On Tue, November 8, 2011 09:37, Graeme Geldenhuys wrote:

> 2011/11/8 Tomas Hajny :
>>
>> Examples?
>
> I can list them all, but I'm not going to waist my time on them again.
> Search the mailing list or Mantis.
>
> But to humour you, here is just one of many examples: THelpEvent in
> the RTL. I proposed a patch to change it to be more in line with FPC's
> goals [being a cross-platform compiler, so requires cross-platform
> solutions]. The change was declined because THelpEvent is a direct
> copy of Delphi's equivalent, and even worse, is very Windows specific
> in its signature. Yes, it's a small and stupid example, but there are
> many more like this. Delphi-compatibility seems to trump everything
> else (as Martin said).

This is a nice example of my reason for asking. What you list here is not
a new feature but change to something what was created in order to provide
Delphi compatibility in the first place. Extending such stuff should be
possible (and has been done many times), changing it by breaking the
compatibility is not necessarily such a good idea.

On the other hand, I don't think that new features are being rejected
because they may add something not available in Delphi (FPC already
provides features not available in Delphi and there is no reason why more
of them shouldn't be added - if they are reasonable and there are people
willing to implement and maintain them.

Tomas


_______________________________________________
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

Martin Schreiber-2
In reply to this post by Marco van de Voort

On Tuesday 08 November 2011 10.56:21 Marco van de Voort wrote:

> In our previous episode, Martin Schreiber said:

> > > nice to have), so please all core developers, stop using that as an

> > > excuse to stop other FPC innovation. Over the years I have heard many

> > > features being declined because they will "not be delphi compatible".

> >

> > I fear the opposite: all Delphi "crap" will be implemented.

>

> Don't worry, there is also room for FPC "crap" ("case string of" e.g.) :-)


Which I like but not use because of Delphi 7 compatibility. :-)


Martin


_______________________________________________
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

Florian Klaempfl
In reply to this post by Graeme Geldenhuys-2
Am 08.11.2011 09:37, schrieb Graeme Geldenhuys:

> 2011/11/8 Tomas Hajny :
>>
>> Examples?
>
> I can list them all, but I'm not going to waist my time on them again.
> Search the mailing list or Mantis.
>
> But to humour you, here is just one of many examples: THelpEvent in
> the RTL. I proposed a patch to change it to be more in line with FPC's
> goals [being a cross-platform compiler, so requires cross-platform
> solutions]. The change was declined because THelpEvent is a direct
> copy of Delphi's equivalent, and even worse, is very Windows specific
> in its signature. Yes, it's a small and stupid example, but there are
> many more like this. Delphi-compatibility seems to trump everything
> else (as Martin said).

So you wanted to break existing stuff other people probably used? It is
indeed one of FPC's policy to avoid breakage of exisiting code.

Or did you propose a TFPHelpEvent?
_______________________________________________
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

Graeme Geldenhuys-2
On 8 November 2011 12:43, Florian Klaempfl <florian@f...> wrote:
> So you wanted to break existing stuff other people probably used? It is
> indeed one of FPC's policy to avoid breakage of exisiting code.

Break what existing code? I searched all of FPC, Lazarus, Lazarus CCR
and MSEgui - there was no existing usage of THelpEvent. Lazarus's LCL
implements there own version of this. So I really didn't see an issue
in changing it in FPC. If you (or Marco - the one that declined my
proposal the first time round) have an example where it would break
existing code, I would love to know about those please.

Now if you want to go down the "delphi compatibility" route, well then
FPC is in the wrong anyway! Neither Delphi, nor Kylix has THelpEvent
defined in the Classes unit, but rather in the Forms.pas unit. So what
delphi is FPC really trying to be compatible with in this case?


> Or did you propose a TFPHelpEvent?

I can't remember the details, but I think I proposed that too. In the
end, I simply defined what I needed in fpGUI itself. Clearly the
latter is the path of least resistance (Martin should agree with his
experiences of MSEgui) - though I do prefer to use existing classes
from FPC (as a first option).

As I said, in the end I defined what I needed in fpGUI itself, using
existing types in the signature, like THelpType and THelpContext  -
which ARE both defined in the RTL, doesn't reek of Windows'ism.

  TfpgHelpEvent = function(AHelpType: THelpType; AHelpContext: THelpContext;
       const AHelpKeyword: String; const AHelpFile: String;
       var AHandled: Boolean): Boolean of object;


--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
_______________________________________________
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

Arioch
In reply to this post by Florian Klaempfl
Florian Klämpfl wrote
>> This is the prototypical way to run a function over each element in a
>> collection, returning the results.
> (map (lambda (x) (+ x 1)) '(1 2 3))
> -> (2 3 4)

I still don't see why this cannot be done by procedure variables: one
can easily pass a procedure reference to a compare function to any sort
library call.
Sorry for resurrecting al thread, but p[erhaps better to keep things together.
1) "anonymous methods" in Delphi are made in very Pascalish way, a lot of wording, a lot of boilerplate.
That adds to readability, but makes their use much harder. If you have relatively complex 4-5 lines function, then the overhead is slightly noticeable. But such functions are a borderline to me, having them anonymous hampers both ease of read and ease of debug. I know C++ fans how say that begin/end are awfully long. Well, Delphi style of anonymous functions would frighten them even more.

Here we are at dilemma. Pascal was devised in 1949 to look like Classic monumental style building, or at least some "manufacturing plant" style building made of bricks industrial way.
Functional style is like more like elegant houses made of paper and thin plywood, something mayeb of Gothic or Japanese style, easily constructible (composable) to any form you like.

They really are hard to make together. You can read about Nemerle and Scala though, about the attempts.

For example in C++ lambdas look total strangers by syntax, but that is inevitable. When you have to type 20 chars of boilerplate for 3 char function "x+y" - that is too much.
http://www.cprogramming.com/c++11/c++11-lambda-closures.html

However, other than that i like syntax for C++ lambda's. It is clearly distinct for compiler, it separates and thus clearly defines captured values, it is rather laconic.

2) however to treat "x+y" as a proper function definition one should have
2.1) either typeless (at compile type, in runtime that may be dynamical typing, duck typing, whatever) language like LISP or Erlang or Python
 even generic function
2.2) or strongly typed language with very sophisticated type infering like Nemerle and Scala
"x + y" is a function, but the compiler should look at the context and make guess what would be the types for x, y and result (latter would usually be least common type for x and y);
So compiler looks at the context and turns - where appropriate - "x + y" into
a generic "function<TX, TY, TRes> (const x:TX; const y:TY): TRes; begin Result := x+y; end; "
Quite a lot to generate of three symbols.
Well, there are even more concise syntaxes, using jokers or omissions.
For example in collection.filter operations the Predicate is expected (it is called collection.Where in Spring4Delphi and MS.Net). So then "_ > 2" or "> 2" would be correct function, implicated to
a generic "function<SomeContextDependantNumericType>  function( const value: SCDNT); begin Result := value>2; end;
It would also be nice for compiler to make some merges.

Surely all that cherries can not be gathered without heavy language and compiler reworking.
Delphi tried to get at least some of those, but 1949 legacy feels there. The question is about possible compromise.

(**** Side note: type inferring is also very useful in Generics. ***)
Some very tiny part of it is even implemented in Delphi :-)

Consider { Chu Jetcheng, 2008-07-24 } http://wiki.freepascal.org/Generics_proposals

var
    Obj1: TGeneric of Integer, Real;
begin
    Obj1 := TGeneric.Create(32, 3.14);

This is quite un-orthodox proposal At the statement, a compiler know the type of Obj1, but does not know the type of TGeneric<X,Y>. Since usually rvalue is parsed with no look at lvalue, such inferring is hardly possible at all. More traditional way would be like

var
    Obj1;
begin
    Obj1 := TGeneric<String, Integer>.Create(32, 3.14);

Where compiler "infers" type of Obj1 looking at the type of value used for assignment.

It is even better if type would be something like
   TEvent<String, Record<Field1, Filed2, Array<Items>>>.
You may say - make an alias.
Type MyEventHere = TEvent<String, Record<Field1, Filed2, Array<Items>>>.

Sometimes that works, for larger code blocks.
But if you have to declare type for every procedure in your unit, that  becomes a mess...

However that is well in the spirit of Wirth.
In 1949 AFAIR you could not have var x: array[0..10] of integer; You should have pre-defined named alias for that array.
And "open arrays" functions parameters of Turbo Pascal 7 would be just a schism and herecy for original Pascal specs.
But we now even have and enjoy dynamic arrays and generalyl do not consider them large enough to have their own dedicated explicitly declared name.

(**** End of Side note. ***)

3) Why that matters ?

You can refactor program with more ease.

Imagine you just want to save some table to... XML file. Or write it to string. Or maybe pass it to some processor, that would check its sanity.

What is the table ? Maybe it is dynamic "array of record ..... end;" ? Or maybe it is TDataSet ? Or maybe it is TStringList.Rows ? Or any of that and who knows what else ?
// that is not that spectacular. TDataSet internals are scarcely documented spaghetti.  When soem in-memory dataset no more compiles in newer Delphi you'd want to change it to dynamic array or TList, but that would ask to re-write all the units using it! You would end up using TClientDataSet and all its TField objects just to pass dynamic array to make a single iteration over it and dispose. Okay, in the world of many-GHz many-core CPUs that does not matter. But "while not q.eof do begin ... q.next; end;" loop is a bit fragile and redundant in wording. //

Okay, you also want to filter it. Your user wants to see customers with most sales.
So he enters a number and only wants to see those whose sales are above.

AFAIR TDataSet had some filtering event (or was it TBDEDataSet), array does not and should be copied.
The logic is very different for same purpose again, depending on source data type style.

But what if there then be one more filtering wished ?
Or what if consumer program needs to apply its internal filtering as well ?

In hypothetical 100% inferring functional style it could look like

procedure Button1OnClick(...);
var Consumer; Data;
begin
      Data := CurrentConsumersCollection;
// array, file object, TDataSet - whatever

      Consumer := ConsumerArray[RadioGroup1.ItemIndex];  
// Save to XML, save to network, show on screen - whatever
 
      if CheckBox1.checked then
         Data := Data.Filter( _.total > StrToInt(editSalesThreshhold.Text );
      if CheckBox2.checked then
         Data := Data.Filter( _.CityCode = StrToInt(editCityCode.Text );
      .....

     Data.Map(Consumer.StepMethod);
(* or Consumer.Process(Data) *)
end;

This function could potentially work with ANY kind of input data containers.

4) And here we come to "capturing" - why those so called "anonymous methods" are better called "closures", why that C++ \starts lambdas not with "()" par but with two pairs "[] ()".

What is the argument type of
  "     Data := Data.Filter( _.CityCode = StrToInt(editCityCode.Text ); " ?

Obviously it only can be a predicate: function<our-data-record-type> (const value:ODRT): boolean;
Otherwise collection should have some fore-knowledge how it would be used later.

Alternatively, it can also have "pointer" second argument, sending all type checking to sewer.
Just how non-Generic TList is practically done. Brr...

Ahem, but how would it get city code to compare ?
We cannot compile 1000 functions with all the reference values of CityCode.
So the function should "capture" value of "StrToInt(editCityCode.Text" from calling place.
In OOP language terms that means we create some object where "StrToInt(editCityCode.Text" is some private field. It is exactly how that is implemented in Delphi - via TInterfacedObject with refcounting.

Compilers sees that the auto-generated function should have StrToInt(editCityCode.Text ) as a parameter from external context. It also knows it is not allowed to have due to argument type of Collection.Filter method being single-argument predicate.
So it behind the hood creates that object with extra parameter like private field.

Other possible approaches ? Well, that FPC wiki page mentions Extended Pascal / GNU Pascal "scheme types", tapes tagged with constant values. That maybe could be extended to be var-tagged.
Then there can be hypothetical "function(code:integer) CompareCityCode(const r: record): boolean" type. If it can somehow be considered derived (okay, assignment-compatible) from mere "function CompareCityCode(...):..." then that would be the same idea mostly.

Most hardcore feature would probably be "partial application", i mentioned Scala but even it has it with limitations.

Imagine we have
function CompareCityCode(const value: our-data-record; const referenceCode: integer): boolean;
begin Result := value.CityCode = referenceCode; end;

What would be result of "CompareCityCode(?, 10)" ? It could be a predicate, it could be new boolean function, having single argument "value" and always comparing with 10.
In VM-based languages like Lisp or Java/.Net that can indeed be implemented as function generator.
In native languages that probably can only be implemented as a hidden object with "10" stored to that private field again.

Why bother ? Well, just imagining how much code and how many functions and names would have be written to implement that spectacular Button1Click with its adapting to different datasources, different consumers, different lists of filters on different conditions, etc.

And then one future day this code - now split to many many dependent procedures and types - have to be reworked.

5) It is hard to implement all that laconic fluid features in "heavy industrial" style language of 1949.
Probably would never happen to Pascal. But some parts, some ideas probably can be implemented still.

For example in Delphi one can not do generic function "x+y" except is both "x" and "y" are classes.
But if they are integers or floats - then compiler cannot make a difference, less so infer the types.
Well, x+y is maybe nonsense, but what about Max(x,y), if it could be implemented generically for any type in single place... Well, again i am passing from lambdas to generics - but their practical use is entangled heavily...

Surely 1949-styled Pascal can not make all that features 1st citizens.
The question is how much and in what style of compromise can be implemented.
Generics were also heresy for original Pascal. But they are implemented, some in Delphi and to some seemingly less extent in FPC as well.

While i pity divergence of syntaxes between Delphi and FPC generics, i strangle would not pity if FPc finally implement lambdas/closures/anonymous-methods in non-Delphi style.
Since Delphi style is so Pascalish, that it heavily limits their practical use.
Reply | Threaded
Open this post in threaded view
|

Re: Delphi's anonymous functions in Free Pascal

Mark Morgan Lloyd-5
Arioch wrote:

> Here we are at dilemma. Pascal was devised in 1949 to look like Classic
> monumental style building, or at least some "manufacturing plant" style
> building made of bricks industrial way.
> Functional style is like more like elegant houses made of paper and thin
> plywood, something mayeb of Gothic or Japanese style, easily constructible
> (compostable) to any form you like.

I'm curious: where do you get this 1948 date from? I'm not even sure
that assemblers (as we know them) existed in 1949...

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

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
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

Sven Barth-2
In reply to this post by Arioch

Am 29.08.2012 22:56 schrieb "Arioch" <[hidden email]>:
> Surely 1949-styled Pascal can not make all that features 1st citizens.
> The question is how much and in what style of compromise can be implemented.
> Generics were also heresy for original Pascal. But they are implemented,
> some in Delphi and to some seemingly less extent in FPC as well.
>
> While i pity divergence of syntaxes between Delphi and FPC generics, i
> strangle would not pity if FPc finally implement
> lambdas/closures/anonymous-methods in non-Delphi style.
> Since Delphi style is so Pascalish, that it heavily limits their practical
> use.

I don't know whether you tested recent versions of FPC, but since 2.6.0 the support for Delphi compatible generics improved, though generic functions/methods and constraints are still missing.

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

michael.vancanneyt
In reply to this post by Arioch


On Wed, 29 Aug 2012, Arioch wrote:

>
> Florian Klämpfl wrote
>>
>>
>>>> This is the prototypical way to run a function over each element in a
>>>> collection, returning the results.
>>> (map (lambda (x) (+ x 1)) '(1 2 3))
>>> -> (2 3 4)
>>
>> I still don't see why this cannot be done by procedure variables: one
>> can easily pass a procedure reference to a compare function to any sort
>> library call.
>>
>
> Sorry for resurrecting al thread, but p[erhaps better to keep things
> together.
> 1) "anonymous methods" in Delphi are made in very Pascalish way, a lot of
> wording, a lot of boilerplate.
> That adds to readability, but makes their use much harder. If you have
> relatively complex 4-5 lines function, then the overhead is slightly
> noticeable. But such functions are a borderline to me, having them anonymous
> hampers both ease of read and ease of debug. I know C++ fans how say that
> begin/end are awfully long. Well, Delphi style of anonymous functions would
> frighten them even more.
I don't think anonymous functions should be added to the compiler at all.

They are IMHO a negation of what pascal stands for. If your programming
style is so strange that you need lamba functions or anonymous functions,
then Pascal is simply not for you.

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

Ralf A. Quint
At 12:09 AM 8/30/2012, [hidden email] wrote:
>I don't think anonymous functions should be added to the compiler at all.
>
>They are IMHO a negation of what pascal stands for. If your programming
>style is so strange that you need lamba functions or anonymous functions,
>then Pascal is simply not for you.
>
>Michael.

+1

I think a lot of people need to get back to program in Pascal...

Ralf

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