Delphi's anonymous functions in Free Pascal

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

Re: Delphi's anonymous functions in Free Pascal

Arioch
> 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.


PasRep.png (88K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Delphi's anonymous functions in Free Pascal

tcoq
In reply to this post by Ralf A. Quint
+1 - anonymous functions demonstrate a laziness to software design: what you can't name you actually don't design...

----- Mail original -----
De: "Ralf A. Quint" <[hidden email]>
À: "FPC-Pascal users discussions" <[hidden email]>
Envoyé: Jeudi 30 Août 2012 09:26:27
Objet: Re: [fpc-pascal] Re: Delphi's anonymous functions in Free  Pascal

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
_______________________________________________
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 Ralf A. Quint
Ralf A. Quint wrote
At 12:09 AM 8/30/2012, [hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Delphi's anonymous functions in Free Pascal

Arioch
In reply to this post by Sven Barth-2
Sven Barth-2 wrote
Am 29.08.2012 22:56 schrieb "Arioch" <[hidden email]>:
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.
Reply | Threaded
Open this post in threaded view
|

Re: Delphi's anonymous functions in Free Pascal

tcoq
In reply to this post by Arioch
I beg to differ. Read Niklaus' work on why he created Pascal: two objectives stand out : readability and ease-of-compiling. He wrote explicitly he wanted a language he could easily write his compiler in...

Sorry rigidity is not part of the original Pascal mandate. Look at Modula and the more recent Active Oberon language, you'll see objects are not in contradiction with those goals that Niklaus had. Units neither. Generics neither. Pointer (typed) neither.

Anonymous functions (or anonymous whatever) is another debate: as i wrote previously, if you can't name it, you can't design it... Pascal is all about good design, visible in the code, readable. 90% of the time a developer reads code, usually somebody else's. This is a well-known statistic. If Pascal optimizes my reading time, I'm all for it! If the new features conform to the readability and ease-of-compiling principles, then go for it! We shouldn't dwell on the Pascal of the early 1970's. I'm fed up of seeing comparisons of 2012 C++ with 1970 Pascal...

Keep up the good work, fpc team!
Best regards,
Thierry

----- Mail original -----
De: "Arioch" <[hidden email]>
À: [hidden email]
Envoyé: Jeudi 30 Août 2012 10:04:08
Objet: [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  -  [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

Arioch
In reply to this post by tcoq
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.
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 Thu, 30 Aug 2012, Arioch wrote:

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

Only pointer math breaks rigidness. The others do not, they enhance it.

Pascal is about readable, clearly structured, strongly typed code.

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

Exactly. If it had been up to me, they would not have been included either.

Till now, I've seen only 1 actual use of generics in general component code,
which kind of supports my theory that the only thing they are useful for is
to create a list and collection kind of classes that do not need typecasts.
which I think is too little justification, because that could have been
achieved differently IMHO.

I started to use lambda functions in Javascript, where they are ubiquitous.
Except for some trivial cases, I ended up naming them anyway, so they could be reused.

I just don't see enough justification for them, given that Pascal offers
enough other structures to achieve the same effect.

Not every conceivable use case justifies a new language feature. Especially
such an abomination as lambda functions, which totally destroys readability.

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

tcoq
In reply to this post by Arioch
No, "can't" is the correct word. In Pascal, one should have the ability to name the constructs one uses. For example, i like very much the ability to name my own Event types:
"type TOnMyEvent = procedure(aStr: string) of object;". Or my Exception types.
Thinking about the event name usually helps me to nail my design.

And you're right, your example is spot on. I use Pascal Analyzer (thanks Peganza!) to check my own programming (as I'm lazy as everybody else), and it detects bad design just like the example you mention. Usually because of the unnamed constant. When I have some time for refactoring, i try removing some of the more offending smells...
What's nice about Pascal is that we all smell them easily... ;-)

Thierry
----- Mail original -----
De: "Arioch" <[hidden email]>
À: [hidden email]
Envoyé: Jeudi 30 Août 2012 10:18:31
Objet: [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  -  [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

Mark Morgan Lloyd-5
In reply to this post by Arioch
Arioch wrote:

> 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;

Except that not defining a distinct type emphasises that the array is
only being declared once, and is not being passed around as a parameter.
So I'd suggest that there are cases where the first example is
appropriate, except obviously that that ..10 is rarely if ever acceptable.

--
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

Arioch
In reply to this post by tcoq
> 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<T> 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();*)
Reply | Threaded
Open this post in threaded view
|

Re: Delphi's anonymous functions in Free Pascal

el_es
In reply to this post by Arioch
On 30/08/2012 09:04, Arioch wrote:

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

You seem to be very rigid over your view of Pascal yourself.
With everything you quoted above (but pointer math) Pascal
is not a toy language any more; unfortunately many recall it
as such and keep pondering about the P language...

(hey, I first had programming classes in middle school
on TP6.0 when the strongest machine in computer class was a 386SX 16MHz;
that the teacher had, we banged on 286...
we had some intro to (Borland) C(++) later on,
but after Pascal, C seemed so obfuscated, I gave up on it and
only write small C programs for microcontrollers where it is
as rigid as Pascal :J )

MvC has a point in saying 'pointer math is what spoils it' -
pointer math is itself a 'feature' dragged into C++ from
'c', the verbose assembler :J

L.

_______________________________________________
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 Mark Morgan Lloyd-5
>> "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.
Reply | Threaded
Open this post in threaded view
|

Re: Delphi's anonymous functions in Free Pascal

Arioch
In reply to this post by el_es
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.  :-)
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 Thu, 30 Aug 2012, Arioch wrote:

>> If the new features conform to the readability
>

[snip]

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

Regarding this: I wish to stress that my views on lambdas or closures are my own;

Other people on the compiler team may have different ideas, so maybe they
will make it into the compiler. Just like Generics did, or advanced records
and some other weird Delphi things of which I totally do not see the use :)

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.

Simply because it is Pascal, after all, and not some C derivative language
(java, C#, Javascript, PHP, Perl whatnot...)

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

Arioch
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Delphi's anonymous functions in Free Pascal

michael.vancanneyt


On Thu, 30 Aug 2012, Arioch wrote:

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

Not really: it breaks my eyes, just as it does in JavaScript :(

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

tcoq
In reply to this post by Arioch
Thank you but I am a professional trainer for C++, Java, Ada and other languages including Lisp. I am "used to" those languages. I consistently see young professionals stumble upon those constructs they are "used to". Furthermore, all the professional users of the developed software are not "used to" and cannot read the implementation of the algorithms they have specified. This is possible and feasible in Pascal with great efficiency.

<snip>
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.
<snip>
_______________________________________________
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 michael.vancanneyt
In our previous episode, [hidden email] said:
> >> 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.
>
> Not really: it breaks my eyes, just as it does in JavaScript :(

This thread is mostly about the semantics and the need.

But what about the implementation? I heard that in Delphi you have to be
careful with anonymous methods because it not always catches expressions and
variables, and that there are many corner cases?

_______________________________________________
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
In reply to this post by Arioch
At 01:18 AM 8/30/2012, Arioch wrote:

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

Sorry, but that example of yours is silly at best. Someone who has
learned to program in Pascal should be able write clearly
understandable programs, not obfuscate just for 'the heck of it'.
But then common sense seems to have turned into a rare commodity these days.

Pascal has evolved since Wirth's original design back in the 70s,
nobody is writing serious programs in the original defined language
set anymore, I dare to day that even ISO Pascal is not all that
useful for real life programs anymore.

A lot of extensions, like units or (objects in general) that you
mentioned have been done in a way that still leave the very basics of
Pascal intact.
But all the fluff that you (and others) are proposing all the time
just aim at completely change the language for no other than
self-serving reasons and that's why people rightfully oppose such proposals...

Ralf

_______________________________________________
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

Jorge Aldo G. de F. Junior
I still fail to see where annonymous functions could succeed where
functional types (part of pascal since last millenia) wouldnt...

2012/8/30 Ralf A. Quint <[hidden email]>:

> At 01:18 AM 8/30/2012, Arioch wrote:
>
>> 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.
>
>
> Sorry, but that example of yours is silly at best. Someone who has learned
> to program in Pascal should be able write clearly understandable programs,
> not obfuscate just for 'the heck of it'.
> But then common sense seems to have turned into a rare commodity these days.
>
> Pascal has evolved since Wirth's original design back in the 70s, nobody is
> writing serious programs in the original defined language set anymore, I
> dare to day that even ISO Pascal is not all that useful for real life
> programs anymore.
>
> A lot of extensions, like units or (objects in general) that you mentioned
> have been done in a way that still leave the very basics of Pascal intact.
> But all the fluff that you (and others) are proposing all the time just aim
> at completely change the language for no other than self-serving reasons and
> that's why people rightfully oppose such proposals...
>
> Ralf
> _______________________________________________
> 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 ... 34567