[fpc-pascal] Re: Delphi's anonymous functions in Free Pascal
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 (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 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. 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.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>>.
You may say - make an alias.
Type MyEventHere = TEvent>>.
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
[fpc-pascal] Re: Delphi's anonymous functions in Free Pascal
> 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 Damn! you're definitely right. At vwery very least Pascal could not be before Algol-68, which could not be before... ahem. But now I wonder myself Here, found it at last look at the picture. I scanned the 1st number looked like year and it just imprinted without any doubt. I remember i was slightly surprised like "so early? such a mighty man!" but just imprinted the number and passed by. I was deep into another theme and year was not important to me, so i just scanned it, noted and went one without single though about possibility. After all computaiton basis like Turing Machine and Lambda Calculus were developed somewhere around those years. At the moment it did seemes unbelievable but not impossible. Really, i embarassed myself, thanks for pointing it. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Delphi-s-anonymous-functions-in-Free-Pascal-tp4911527p5711050.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] Re: Delphi's anonymous functions in Free Pascal
Ralf A. Quint wrote > > At 12:09 AM 8/30/2012, michael.vancanneyt@ wrote: >>They are IMHO a negation of what pascal stands for. If your programming > +1 > Well, the same should be told about everything modern pascal is. Open and dynamic arrays, pointer math, objects, generics, even units. It was all breaking the initial Pascal strictness and rigidness. Because what was counted "large blocks" deserving their own explicit naming back then - now seems trivial small detail. Generics are alien to Pascal no more no less than closures. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Delphi-s-anonymous-functions-in-Free-Pascal-tp4911527p5711052.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] Re: Delphi's anonymous functions in Free Pascal
Sven Barth-2 wrote > > Am 29.08.2012 22:56 schrieb "Arioch" <AriochThe@>: > 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. > Thanks. No, i just checked wiki and docs and referenced mailing lists letters. Last time i worked with Lazarus were times of Linux transition from 2.4 to 2.6. Don't recall exactly but that was ooold times :-) Personally i think that introducing yet more keywords is not good thing, when can be avoided. But since it was done, i did not think that FPC would both implement their native syntax with generics/specialize keywords and keywordless Delphi style. Lack of generic methods and corresponded partially to it lack of modern RTTI is pity, but hopefully would be resolved. PS. Checking available docs, besides, was how i came to the topic and was wondered that no one answered why closures matter. It is surely personal test to like or dislike them. I already said that they can make code hardly readable and hardly debugable is over-used. And that Delphi model of them makes them impractical for oneliners (where their true power lies) and only practical for complex routines (where they are problematic) Howeveri wished that their benefits at least were outlined in the thread, referenced from wiki. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Delphi-s-anonymous-functions-in-Free-Pascal-tp4911527p5711054.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] Re: Delphi's anonymous functions in Free Pascal
tcoq wrote > > a laziness to software design: what you can't name you actually don't > design... > Guess you meant "don't want to" instead of "can't" And You mean all the non-named arrays, don't you. "var x: array[0..10] of integer; " is not only violating Pascal Report, but also is twice lazy. since one should name every part of design one should type like type SomeEnumSemanticName = 0..10; SomeEnumMapSemanticName = array[SomeEnumSemanticName] of integer; var x: SomeEnumMapSemanticName; That has a point, for self-documenting if nothing else. But i don't believe it is practically that pervasive as your stated maxima would assume. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Delphi-s-anonymous-functions-in-Free-Pascal-tp4911527p5711056.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] Re: Delphi's anonymous functions in Free Pascal
> If the new features conform to the readability That heavily depends upon which patterns are known to reader. We all are patterns recognizers. And today world is very different. In my example sketch, the calling like "Data.Filter( _.TotalSale > 20 )" is concise and easy to understand. Okay, given your heavy Pascal background you would stumble because you would see the thing between bracket as an unbelievable heresy. For people without Pascal background that would be easy to read. At least easier than scrolling into 3 different functions probably belonging to different objects that would implement the same idea in traditional imperative way. Generics are the ease of reading ? i saw a lot of posts calling Boost and "Modern C++ Programming" nothing else than perversion. And the enigma of generics-related compiling error messages are but a common point. But surely remembering single TList is easier than remembering dozen of specialized TLists. It is all about scale and experience. And we are now recognizing larger blocks of code, than in seventies. Atoms are larger today. Can closures be abused ? Easily. Can generics be abused ? easily. Can pointers be abused? For sure. Strings ? After i saw the tutorial(sic!) on database access, that compared word (two bytes) values via "IntToHex(value, 2) = string-constant" i am sure they easily can. When you think about ease to read i believe you should compare to values. * How easier would be code to read when the feature used properly ? * How harder code would be to read when the feature is misused ? Frankly, i don't know what weights should those values have, but i tend to believe 1st is more important. You can always make spaghetti copy-pasted code with anything. 5 lines anonymous functions are hard to debug and separate from surrounding code. 10 lines ones would be nightmare. 1-2 liners are heavily simplifying reading, where they can be applied. > and ease-of-compiling principles Generics are one more indirection layer for compiler to care about. They are not simplifying compiling. And they make dynamic modules like Delphi BPLs no more self-contained. Objects are not easying compiler - now compiler should care about hidden Self parameter and generate different code for seemingly the same function, if it is method or detached function. And i did not mentioned viortual methods and properties yet. Ref-counted interfaces are even more burden. Dynamic arrays and strings are not easying compilation - they require a lot of hidden "compiler magic" in each statement using them. Supporting multiple platforms, supporting multiple Pascal extensions - it all has its price making compilation more complex. Easy compiling is good goal in the row of other ones. It has its weight but it is quite far from absolute. - 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. 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. Everything is compromise, with it bright and dark sides. And everything has its personal bets in every compromise. Allow me to congratulate you all with Lazarus 1.0 release and thank you with good and practical language implementation. Have a nice TimeOfDay();*) -- 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] Re: Delphi's anonymous functions in Free Pascal
>> "var x: array[0..10] of integer; " also is twice lazy. >> type >> SomeEnumSemanticName = 0..10; >> SomeEnumMapSemanticName = array[SomeEnumSemanticName] of integer; >> var x: SomeEnumMapSemanticName; > Except that not defining a distinct type emphasises that the array is > only being declared once, Same for closures, exactly. The function is represent some primitive action or criteria that is not worth re-using and clattering namespace in both compiler and developer. More so, i believe that holds for all named/non-named entities. Be it array, value, function of if/while condition, etc The thing that is not named is small, with narrow use span, and is expected to be recognized and read by human as some kind of "reading atom" The thing named is more about architecture and documentation. > and is not being passed around as a parameter. Be that the case - there would be no Open Array parameters. //well, i just want to say my opinion here. I frankly don't want arguing yet another topic // > So I'd suggest that there are cases where the first example is > appropriate, except obviously that that ..10 is rarely if ever acceptable. if 10 is unacceptable then so is 0. one should rather explicitly name type for (0..10) rather than two constants for 0 and for 10. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Delphi-s-anonymous-functions-in-Free-Pascal-tp4911527p5711062.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] Re: Delphi's anonymous functions in Free Pascal
Pascal never was a toy language. It always have too much required naming-and-declarations/boilerplate/obstacles/you-name-it Basic, Logo - let them be. But not the Pascal. It was educational language but it was damn serious educational language. However i believe that your "but pointer math" is only a matter of habit. Function pointers, virtual methods, interfaces - they all mean when you see function call you don't know which function is actually called. You think of them as easing the reading only because you got used to them. You mastered those concepts and recognition patterns. Show that code to old school Classic Basic programmer, and he would flee in awe. For a long time i sticked to Delphi 5 and did not see any benefit to upgrade, so i understand programming in classic ObjectPascal. But call me spoiled, I finally switched to XE2 and generics and closures do simplify code. But of course when and after you make them patterns you recognize at 1st glance. So, habits. Well, finally good bye. :-) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Delphi-s-anonymous-functions-in-Free-Pascal-tp4911527p5711063.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] Re: Delphi's anonymous functions in Free Pascal
> Regarding this: I wish to stress that my views on lambdas or closures are my own; For what i understand, those are different things. Lambdas are runtime code generators and are out of question for natively compiled language. Closures are not. Maybe that is nitpicking today, since the names seems to be substituting each other outside functional languages realm where those concepts were born. > But - and I think the whole compiler team shares this idea - if implemented, > it will be in a pascal-ish way, i.e. rather verbose. Well, views for views. That is Delphi way you describe. Beauty of principles. And that would be harmingly impractical. Closures are about concise way to express one-liners. If you have to type 30 chars instead of 3 - their use became hard and impractical. This would suppress using closures for one-liners, where that are useful, safe and enhancing code readability and composability. That would promote their use for complex code chunks where they are dangerous and bad. >From personal experience, when i first time saw how pascalish is closures implementation in Delphi i just admired the ease in which that concept was fused into the language of very different style built upon very different ideas. It was so elegant when reading docs, i admired it. Like probably you do. But that next to ruined their use in practice. That is where i loose my consistency. I do want Delphi and FPC have shared libraries, which mean i want FPC to support as much Delphi syntax as feasible. I do want generics in both and hence want FPC support Delphi generics syntax. I do want closures in both and... and completely cold-hearted if FP would support Delphi syntax of them or not. While generally i feel kind of disgust at C syntax, i have to admit that their so-called lambdas are ugly but might be practical. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Delphi-s-anonymous-functions-in-Free-Pascal-tp4911527p5711067.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] Re: FPC class syntax was extended to support delphi code
В письме от Thu, 14 Jan 2010 18:50:50 +0400, Andreas Schneider сообщал: Can FPC have default class properties in Delphi mode or even ObjFpc mode? i probably won't really do it, for my major concern is still Delphi, and that makes a special note that "defaul" and "class" are mutually exclusive. Pity... i wished to do a light-weight factory (which Delphi class references are to an extent). I would have to resort to global procedure, but that is less elegant. And calling TClassName.a(DataPayload) is awful. TClassName[DataPayload] would be neat... I think they come in very handy for the Singleton OOP concept. You need to have a "factory" that handles the object query/instantiation. If no instance is available, it creates a new one (and stores it) and if one is already available, it just returns that. Naturally that looks better to have TSomeClass.GetInstance() instead of GetInstanceOfSomeClass() ... Sure, it's possible to do without class methods, but from an OOP viewpoint it just looks and feels wrong ;-) (imho) -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
