Re: [fpc-pascal] A new fpc desirable feature

[Tomas Hajny]

On Tue, July 17, 2018 19:49, Dmitry Boyarintsev wrote:
> Please, fpc-other please

Indeed - please, everybody make sure to keep the discussion on this list
on topic, this thread doesn't belong to this list.

Tomas
(one of FPC mailing list moderators)


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

Re: [fpc-pascal] Syntax changes suggestions

[Jim Lee]

On 07/17/18 13:28, Ryan Joseph wrote:
If I’m doing work I don’t have to, merely knowing that Pascal has 
remained pure to the original specification is not very much comfort 
to me.


I'm not advocating for purity.  I'm advocating for diversity.  I don't 
want to see Pascal become MumbleScript, or whatever the hot language of 
the week happens to be.


-Jim

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

Re: [fpc-pascal] Syntax changes suggestions

[Martin]

On 07/17/18 11:50, Ryan Joseph wrote:


If lots of programmers using main stream languages like c++ are 
having a similar problem we are I think it’s incumbent for Pascal to 
at least consider if there is merit to the concern.






So if a lot of programmers find it bad to have to much freedom, then it 
is good if it is restricted?


Because take JavaScript, well there freedom of declaring variables is 
even less restricted, than was asked for in this thread.
But it seems that many JavaScript developers got frustrated with that. 
So much that the now have external tools to restrict that freedom


http://www.adequatelygood.com/JavaScript-Scoping-and-Hoisting.html
https://eslint.org/docs/rules/vars-on-top

This is not directly related to the original post/request.
But it shows that the statement quoted on top is severely dangerous.

Just because another language has a feature, or even because many use it 
(where it is not know what expertise those have, nor how many do not use 
it)...
Just because any of this, does by no means indicate that such a feature 
is any good at all.


Just because c++ has the feature does not mean that it solves any 
problem that c++ programmers would otherwise have. It can same as good 
mean the opposite.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Jim Lee]

On 07/17/18 13:28, Ryan Joseph wrote:



On Jul 17, 2018, at 2:07 PM, Jim Lee  wrote:

And that's why I hesitate whenever someone comes along and says we should add 
 to Pascal

I just want my life to be easier and to enjoy programming in Pascal as much as 
possible. If I’m doing work I don’t have to, merely knowing that Pascal has 
remained pure to the original specification is not very much comfort to me.



That's why we have more than one language to create programs with. It's 
not possible to use one language in all domains with an equal amount of 
ease in each domain.


Think of human languages.  You cannot describe the operation of an 
internal combustion engine and the operation of performing an 
appendectomy with the same, plain English vocabulary.  Each requires the 
use of jargon specific to the domain.   So it is with programming 
languages - if we added the "jargon" necessary to cover every domain in 
a single language, that language would be unintelligible.


-Jim


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

Re: [fpc-pascal] Syntax changes suggestions

[Sven Barth via fpc-pascal]

Am 17.07.2018 um 22:32 schrieb Ryan Joseph:



On Jul 17, 2018, at 2:15 PM, Sven Barth via fpc-pascal 
 wrote:

Those specific features you mention were added because of Delphi compatibility 
not because someone thought they are good. Florian even likened records with 
methods to a can of worms before they were implemented.

Maybe FPC needs a fork or something that keeps the original specification, or 
going the other way an experimental branch? Florian amongst others must be 
really annoyed with how this is all going and I sympathize with them.

FPC appears to have group of users who are purists (or something like that), 
Delphi users, and utilitarians (if that’s accurate a description) that want the 
language to evolve to meet current trends/demands of the industry, e.g. if 
there’s a good idea floating around out there I want to use it also.

Going forward how is this going to be resolved?
There is a more important difference: the developers and the users. Only 
because the latters think an idea is good or probable the former do not 
necessarily need to agree. And don't forget that we, the developers work 
on this in our free time and thus don't have any interest on spending 
time on features that we don't believe in.


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

Re: [fpc-pascal] Syntax changes suggestions

[Ryan Joseph]

> On Jul 17, 2018, at 2:15 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> Those specific features you mention were added because of Delphi 
> compatibility not because someone thought they are good. Florian even likened 
> records with methods to a can of worms before they were implemented.

Maybe FPC needs a fork or something that keeps the original specification, or 
going the other way an experimental branch? Florian amongst others must be 
really annoyed with how this is all going and I sympathize with them. 

FPC appears to have group of users who are purists (or something like that), 
Delphi users, and utilitarians (if that’s accurate a description) that want the 
language to evolve to meet current trends/demands of the industry, e.g. if 
there’s a good idea floating around out there I want to use it also.

Going forward how is this going to be resolved?

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Syntax changes suggestions

[Ryan Joseph]

> On Jul 17, 2018, at 2:07 PM, Jim Lee  wrote:
> 
> And that's why I hesitate whenever someone comes along and says we should add 
>  to Pascal

I just want my life to be easier and to enjoy programming in Pascal as much as 
possible. If I’m doing work I don’t have to, merely knowing that Pascal has 
remained pure to the original specification is not very much comfort to me.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Syntax changes suggestions

[Sven Barth via fpc-pascal]

Am 17.07.2018 um 20:00 schrieb Ryan Joseph:



On Jul 17, 2018, at 11:27 AM, Jim Lee  wrote:

Likewise, "modern" programming languages are all converging on a common feature 
set, like cultural cross-pollination.

if that’s our mindset then how do we account for times when we’ve actually 
identified a common pattern that a language feature could address? I’m thinking 
of things like methods in records, for..in loops etc… that made it into the 
language and are widely adopted and enjoyed.
Those specific features you mention were added because of Delphi 
compatibility not because someone thought they are good. Florian even 
likened records with methods to a can of worms before they were implemented.


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

Re: [fpc-pascal] Syntax changes suggestions

[Jim Lee]

On 07/17/18 11:50, Ryan Joseph wrote:



On Jul 17, 2018, at 12:24 PM, Jim Lee  wrote:

It has to fit the spirit of the language as well.

I don’t propose new features to copy other languages but I’ll mention other 
languages as evidence that more people than just myself have discovered some 
merit to the concept (i.e. a form of validation). When I say c++ does ___  too 
I take that as a good indication many other programers who work in a similar 
language had the same problem I did.

If lots of programmers using main stream languages like c++ are having a 
similar problem we are I think it’s incumbent for Pascal to at least consider 
if there is merit to the concern.



I disagree.

Pascal is a language (originally) intended to be used to teach 
structured programming concepts, and also to be a practical production 
language *in that same domain*.


When Mr. Wirth saw the merits of modular programming, he did not try to 
retrofit that functionality into Pascal - he instead created a new 
language, Modula-2, and later, Modula-3.


When Mr. Wirth later saw the merits of object oriented programming, he 
did not try to retrofit that functionality into Pascal or Modula - he 
instead created a new language, Oberon.


On the other hand, both Apple and Borland chose to extend their versions 
of Pascal with these newer concepts (and several others), turning Pascal 
into a multi-paradigm language.  That was in the day and time when 
commercial interests were more important than language design.  It was 
also a time when products were judged by the number of features 
included, not by their quality.


Now, I happen to think that both structured and modular programming 
belong together, and that Wirth could have added modular extensions to 
Pascal without destroying the spirit of the language.  However, what is 
known as "Object Pascal", to me, should be a separate language, with a 
different name.   Not better, not worse, just different.  And that's why 
I hesitate whenever someone comes along and says we should add of the day> to Pascal.


-Jim

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

Re: [fpc-pascal] Syntax changes suggestions

[Martin]

On 17/07/2018 15:34, Michael Van Canneyt wrote:



On Tue, 17 Jul 2018, Vojtěch Čihák wrote:


Hi,

Lazarus has option "Show Class/Proc Hint" which displays method name 
(with light-green background) as the top line in source editor, only 
if the method's body is longer than number of lines in source editor.
Maybe new option "Show Proc var block" for permanent displaying var 
block in long methods would be enough? Jumps between code and 
declaration would not be needed.


If such a thing is implemented, then why not make it as the 'local 
variables' debug dialog, a separate floating window, maybe stay-on-top  ?


If you put it at the top of the source editor, it risks to take a lot 
of space out
of the source editor window, which kind of defeats the purpose, I 
suppose.

- Clone the current source editor, so you get another window.
- Scroll it to the block you want
- Resize it as needed
- Select "Lock Page" from the tabs popup menu
  (This will prevent, codetools from scrolling this window, if you 
navigate in the unit)


The result:
- you keep the variables in view
- if you "jump to declaration" of a variable (that is not visible in the 
current window), it will jump to it in the "locked" window
- if you jump back to previous location, you will be back in the 
unlocked window


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

Re: [fpc-pascal] Syntax changes suggestions

[Ryan Joseph]

> On Jul 17, 2018, at 12:24 PM, Jim Lee  wrote:
> 
> It has to fit the spirit of the language as well.

I don’t propose new features to copy other languages but I’ll mention other 
languages as evidence that more people than just myself have discovered some 
merit to the concept (i.e. a form of validation). When I say c++ does ___  too 
I take that as a good indication many other programers who work in a similar 
language had the same problem I did.

If lots of programmers using main stream languages like c++ are having a 
similar problem we are I think it’s incumbent for Pascal to at least consider 
if there is merit to the concern.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Syntax changes suggestions

[Jim Lee]

On 07/17/18 11:00, Ryan Joseph wrote:



On Jul 17, 2018, at 11:27 AM, Jim Lee  wrote:

Likewise, "modern" programming languages are all converging on a common feature 
set, like cultural cross-pollination.

if that’s our mindset then how do we account for times when we’ve actually 
identified a common pattern that a language feature could address? I’m thinking 
of things like methods in records, for..in loops etc… that made it into the 
language and are widely adopted and enjoyed.

Regards,
Ryan Joseph

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


Well, if we keep with the cultural parallel, in all cultures people must 
eat, sleep, drink, be born and die, etc.  There are a number of 
commonalities simply because all involve humans.  My point is that a 
language should not adopt a feature simply because it is useful in 
another language.  It has to fit the spirit of the language as well.


Be careful of thinking that "useful" means "I can do the same thing in 
language X in the same way I do it in language Y".  Eventually, X == Y.


-Jim

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

Re: [fpc-pascal] Syntax changes suggestions

[Ryan Joseph]

> On Jul 17, 2018, at 11:27 AM, Jim Lee  wrote:
> 
> Likewise, "modern" programming languages are all converging on a common 
> feature set, like cultural cross-pollination.

if that’s our mindset then how do we account for times when we’ve actually 
identified a common pattern that a language feature could address? I’m thinking 
of things like methods in records, for..in loops etc… that made it into the 
language and are widely adopted and enjoyed.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] A new fpc desirable feature

[Dmitry Boyarintsev]

Please, fpc-other please
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Jim Lee]

On 07/17/18 07:49, Marco van de Voort wrote:


Worse, IMHO creeping unnecessary dialect change is worse than remaining
different. The spread of codebases over the various subdialects is worse than 
any
benefits these half assed extensions can ever have. It is spreading language
development thin instead of deep




Agreed.

This can be likened to the spread of globalization among cultures. 
Uniqueness and charm suffer at the hand of cross-pollination.


You can go almost anywhere in the world today and find icons of Western 
culture.  Starbucks in Sri Lanka.  McDonalds in Shanghai.


Likewise, "modern" programming languages are all converging on a common 
feature set, like cultural cross-pollination.


I prefer to have a variety of dialects and paradigms to choose from (and 
a variety of cultures) over a global sameness.


-Jim


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

Re: [fpc-pascal] A new fpc desirable feature

[Jim Lee]

On 07/17/18 04:56, Giuliano Colla wrote:
As everybody is suggesting new fpc features, I feel it right to add my 
own proposal, to make the language more useful and user friendly.


I propose the support for the keyword "please".

The syntax is quite simple: "please:", followed by the explanation in 
plain English (or whatever locale is selected) of what you want the 
compiler to do, makes the compiler generate the appropriate code.


E.g. :

please: fetch from the database xxx the relevant data and put them 
neatly in a string grid;
please: if the user modifies the data in the string grid, update the 
database accordingly;


I hope that this simple request will not be rejected, even if it is in 
line with most of the requests I read in this list and which face 
strong resistance from core developers :-).


Giuliano




And don't forget:

The final line of the program must end with "Thank you."

-Jim


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

Re: [fpc-pascal] A new fpc desirable feature

[wkitty42]

On 07/17/2018 11:56 AM, Giuliano Colla wrote:

A problem would be to determine the appropriate amount of politeness
accepted. >
Maybe a compiler option, such as -P0 (almost rude) to -P3 (extremely polite)?
Or up to -P7 for an increased granularity?


go the other way... a P9 is a weapon... to carry the analogy along, if you are 
using a weapon to achieve a desired goal, you're not necessarily being polite... 
-P9 would be maximum ""rudeness"" (aka not polite at all)... -P0 would be 
maximum politeness (aka not rude at all)...


-=B-)


--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ryan Joseph]

> On Jul 16, 2018, at 11:20 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> Because they are programmers. They simply do it their way. And I'm especially 
> talking about code written by two different programmers, one storing the 
> instance somewhere and the other passing in an "auto" instance without 
> knowing that the other programmer is storing it somewhere.
>> Auto is a good idea. Allocating the “auto” classes the memory backend on the 
>> stack (my “stack alias” idea) is even better because you don’t need the 
>> memory manager too be involved.
> No, it's not. And we don't *want* to change the paradigm of TObject.

The reason we propose these things is because of a manifest observable need 
that we experience daily. We’re not proposing things like making Pascal garbage 
collected or ARC for all objects like new languages are. These are practical 
and optional solutions that programmers can use depending on their needs.

Firs off, yes I know this isn’t Pascal objects but look at this entirely 
predictable block of code that I found after searching for 10 seconds. 
Dynamically allocating memory which I *know* beyond a shadow of a doubt will 
only survive this function. There’s not going to be any passing around. I know 
this. 

Predictably at the end of the function I review all the memory I allocated and 
free it. Why couldn’t I just tell the compiler I want this freed at the time I 
declare the variable? I know then and I don’t want to think about it again. 
This is such an obvious pattern to optimize in the language. This is not that 
crazy guys.

colorSpace := CGColorSpaceCreateDeviceRGB;
bitmapInfo := kCGImageAlphaFirst or kCGBitmapByteOrder32Little;
provider := CGDataProviderCreateWithData(nil, bytes, bytesCount, nil);
imageRef := CGImageCreate(width, height, 8, 32, bytesPerRow, 
colorSpace, bitmapInfo, provider, nil, 1, kCGRenderingIntentDefault);

finalImage := NSImage.alloc.initWithCGImage_size(imageRef, 
NSMakeSize(width, height));
imageData := finalImage.TIFFRepresentation;
imageRep := NSBitmapImageRep.imageRepWithData(imageData);
//imageProps := 
NSDictionary.dictionaryWithObject_forKey(NSNumber.numberWithFloat(1), 
NSImageCompressionFactor);
imageData := imageRep.representationUsingType_properties(fileType, 
imageProps);
imageData.writeToFile_atomically(NSSTR(path), false);

// <——— freeing stuff ———>
CFRelease(provider);
CFRelease(imageRef);
CFRelease(colorSpace);
finalImage.release;

var
  colorSpace: CGColorSpaceRef;
  provider: CGDataProviderRef;
  imageRef: CGImageRef;
  finalImage: NSImage;


Regards,
Ryan Joseph

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

Re: [fpc-pascal] A new fpc desirable feature

[Giuliano Colla]

Il 17/07/2018 14:12, Karoly Balogh (Charlie/SGR) ha scritto:

  I also propose that if you do not write "please" often enough,
the compiler would error out, claiming the user being too rude. But if
it's used too often, the source can be rejected for being excessively
polite.


A problem would be to determine the appropriate amount of politeness 
accepted.


Maybe a compiler option, such as -P0 (almost rude) to -P3 (extremely 
polite)? Or up to -P7 for an increased granularity?


Giuliano

--
Do not do to others as you would have them do to you.They might have different 
tastes.

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

Re: [fpc-pascal] A new fpc desirable feature

[Giuliano Colla]

Il 17/07/2018 16:06, Reimar Grabowski ha scritto:

I DO NOT beg the compiler for something, I command.


Then I would not be astonished if it turned out that you experience more 
troubles than the average, such as unexpected sigsev, libraries not 
found, unexpected shutdowns, and disk errors.


I have learned from Russians that the computer must be treated gently. 
In Russian the word for computer is feminine, and they say that it must 
be treated as such. Gently and with love. Be kind with your computer and 
he (she) will be kind to you! :-)


Giuliano

--
Do not do to others as you would have them do to you.They might have different 
tastes.

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

Re: [fpc-pascal] Syntax changes suggestions

[Sven Barth via fpc-pascal]

Marco van de Voort  schrieb am Di., 17. Juli 2018, 16:50:

> To be honest, I'm wondering why Sven actually bothers to answer this
> nonsense.
>

Trust me, I wonder the same 

Regards,
Sven

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

Re: [fpc-pascal] Syntax changes suggestions

[Marco van de Voort]

In our previous episode, Mark Morgan Lloyd said:
> However, I do wish that people wouldn't resort to that same old 
> chestnut. There ought to be a Pascal discussion equivalent of Godwin's 
> Law: "sooner or later in any debate about a language feature somebody 
> will complain that it's too much like C".

That sounds very negative, but one must not forget that this only is a
response to a halfassed copy syntax-from-language-x request. And everything
is always demonstrated with 4 line examples, no analysis how it fits in the
parsing structure nothing.

To be honest, I'm wondering why Sven actually bothers to answer this
nonsense.
 
> Frankly, who cares? are we really all so insecure that we can't 
> accommodate even the suggestion that "our opponents" occasionally have a 
> good idea?

"Good idea" is terribly subjective as already made clear in this discussion,
opinions vary wildly.

Are we so insecure that we must copy every alien bit of syntax? No.

Worse, IMHO creeping unnecessary dialect change is worse than remaining
different. The spread of codebases over the various subdialects is worse than 
any
benefits these half assed extensions can ever have. It is spreading language
development thin instead of deep

P.s. people that disagree should start arguing for an unit/module concept
on C groups, and use the exact same reasoning. Please post the URL, and I'll
follow the thread with a bucket of popcorn.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A new fpc desirable feature

[Reimar Grabowski]

On Tue, 17 Jul 2018 13:56:39 +0200
Giuliano Colla  wrote:

> The syntax is quite simple: "please:", followed by the explanation in 
> plain English (or whatever locale is selected) of what you want the 
> compiler to do, makes the compiler generate the appropriate code.

Not against you but that's the most stupid proposal I ever heard.
I DO NOT beg the compiler for something, I command.

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

Re: [fpc-pascal] Syntax changes suggestions

[Reimar Grabowski]

On Tue, 17 Jul 2018 12:04:19 +0200
Martin  wrote:

> But more troubling:
> You do no longer have a complete list of all local vars. That means, if 
> I want to add a (current style) local var "i", i may have to scan the 
> entire procedure (maybe hundreds of lines) to find if there already is a 
> nested "i"
Wouldn't you need to refactor this procedure anyway into 20 line chunks and 
nuke the guy that wrote it? ;)

Btw I don't support the proposed changes as I don't see the need to get all and 
every language on feature parity.
Languages do have different design philosophies which manifest in different 
feature sets. So there is always more to a feature than pure functionality.
I write nowadays mostly in languages which do have "block scope" and I really 
don't prefer one "scoping" over the other. Both make sense in the context of 
their respective language.
And Delphi for example introduced features in a vain attempt to stay relevant 
which where not in the spirit of pascal. Freepascal has no need to do this.

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

Re: [fpc-pascal] Syntax changes suggestions

[Vojtěch Čihák]

Maybe it should be extension of Code Explorer.
 
I did a quick calculation, I have 1680x1050 laptop display and I can see 40 
lines of code in Source Editor, i.e. 39+1 method name for long methods.
If the var block has ~8 lines, then it would remain 31 lines for code, it is 
still accepatable. And I guess programmers have usually bigger displays.
 
V.
 
__

Od: Michael Van Canneyt 
Komu: FPC-Pascal users discussions 
Datum: 17.07.2018 15:34
Předmět: Re: [fpc-pascal] Syntax changes suggestions




On Tue, 17 Jul 2018, Vojtěch Čihák wrote:

> 
If such a thing is implemented, then why not make it as the 'local variables' debug 
dialog, a separate floating window, maybe stay-on-top  ?


If you put it at the top of the source editor, it risks to take a lot of space 
out
of the source editor window, which kind of defeats the purpose, I suppose.

Michael.

--

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

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

Re: [fpc-pascal] Syntax changes suggestions

[Michael Van Canneyt]

On Tue, 17 Jul 2018, Vojtěch Čihák wrote:


Hi,
 
Lazarus has option "Show Class/Proc Hint" which displays method name (with 
light-green background) as the top line in source editor, only if the 
method's body is longer than number of lines in source editor.
Maybe new option "Show Proc var block" for permanent displaying var block in 
long methods would be enough? Jumps between code and declaration would not be 
needed.


If such a thing is implemented, then why not make it as the 'local variables' debug 
dialog, a separate floating window, maybe stay-on-top  ?


If you put it at the top of the source editor, it risks to take a lot of space 
out
of the source editor window, which kind of defeats the purpose, I suppose.

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

Re: [fpc-pascal] Syntax changes suggestions

[Mark Morgan Lloyd]

don't like looking at such C code, so why would I want that in Pascal


This is not my fight because TBH I'm inclined to avoid novel language 
features until I know that using them won't impact on some of the older 
kit I try to keep stuff compiled for.


However, I do wish that people wouldn't resort to that same old 
chestnut. There ought to be a Pascal discussion equivalent of Godwin's 
Law: "sooner or later in any debate about a language feature somebody 
will complain that it's too much like C".


Frankly, who cares? are we really all so insecure that we can't 
accommodate even the suggestion that "our opponents" occasionally have a 
good idea?


Besides which, in-block declarations predate C: it's the way that 
ALGOL-60 did it. And ALGOL-60 put the type before the variable in a 
declaration, had in-expression conditionals and so on: all things I've 
seen rejected offhand as "too much like C".


So come on chaps, at least get your history right and say that you 
prefer the Pascal way and won't have any ALGOL crap messing it up.


Pax vobiscum.

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

Re: [fpc-pascal] Syntax changes suggestions

[Vojtěch Čihák]

Hi,
 
Lazarus has option "Show Class/Proc Hint" which displays method name (with 
light-green background) as the top line in source editor, only if the method's body is 
longer than number of lines in source editor.
Maybe new option "Show Proc var block" for permanent displaying var block in 
long methods would be enough? Jumps between code and declaration would not be needed.
 
V.
__

Od: Michael Van Canneyt 
Komu: FPC-Pascal users discussions 
Datum: 17.07.2018 12:30
Předmět: Re: [fpc-pascal] Syntax changes suggestions



Exactly: I do scope them. I make small routines.

Reducing scope to 5 lines in a routine of 20 lines is a waste of time.

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

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

Re: [fpc-pascal] A new fpc desirable feature

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 17 Jul 2018, Giuliano Colla wrote:

> As everybody is suggesting new fpc features, I feel it right to add my
> own proposal, to make the language more useful and user friendly.
>
> I propose the support for the keyword "please".
>
> The syntax is quite simple: "please:", followed by the explanation in
> plain English (or whatever locale is selected) of what you want the
> compiler to do, makes the compiler generate the appropriate code.

Great idea! I also propose that if you do not write "please" often enough,
the compiler would error out, claiming the user being too rude. But if
it's used too often, the source can be rejected for being excessively
polite.

Also maybe it could TRY to a hint an info and warning about this EXCEPT if
the code is bogus anyway, before FINALLY erroring out. :-)

Charlie

(Ps: https://en.wikipedia.org/wiki/INTERCAL )
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] A new fpc desirable feature

[Giuliano Colla]

As everybody is suggesting new fpc features, I feel it right to add my 
own proposal, to make the language more useful and user friendly.


I propose the support for the keyword "please".

The syntax is quite simple: "please:", followed by the explanation in 
plain English (or whatever locale is selected) of what you want the 
compiler to do, makes the compiler generate the appropriate code.


E.g. :

please: fetch from the database xxx the relevant data and put them neatly in a 
string grid;
please: if the user modifies the data in the string grid, update the database 
accordingly;

I hope that this simple request will not be rejected, even if it is in 
line with most of the requests I read in this list and which face strong 
resistance from core developers :-).


Giuliano


--
Do not do to others as you would have them do to you.They might have different 
tastes.

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

Re: [fpc-pascal] Syntax changes suggestions

[Michael Van Canneyt]

On Tue, 17 Jul 2018, Henry Vermaak wrote:


On Tue, Jul 17, 2018 at 12:07:10PM +0200, Michael Van Canneyt wrote:

>On Tue, Jul 17, 2018 at 11:14:31AM +0200, Michael Van Canneyt wrote:
If you need to "reduce the scope of variables", your routines are too long to
begin with.

If of course you write routines of several hundreds of lines (or thousands),
then you probably would need to have such a feature.

But I would fire any programmer that writes such code anyway, since it
indicates he cannot think structured.


And I'd fire any programmer that doesn't properly scope their variables,
just as you'd (hopefully) fire a programmer for using global instead of
function level variables.


Exactly: I do scope them. I make small routines.

Reducing scope to 5 lines in a routine of 20 lines is a waste of time.

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

Re: [fpc-pascal] Syntax changes suggestions

[Michael Van Canneyt]

On Tue, 17 Jul 2018, Martin wrote:


On 17/07/2018 11:05, Henry Vermaak wrote:

On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:

Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:


I have some suggestions of change to freepascal syntax, just to debate

(All are backward compatible)

- Declaring variables inside blocks, and loop variables


-> reduces readability -> no interest

How can it reduce readability?  You move variables closer to where they
are used, therefore reducing clutter in the main "var" section.
Limiting variable scope is definitely a good thing, I sure hope you're
not arguing against that.  That's why almost all languages encourage it.



[snip]



If you have a scoping problem in pascal, cut your code into smaller 
procedures.


Which is what I have been saying all along...

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

Re: [fpc-pascal] Syntax changes suggestions

[Henry Vermaak]

On Tue, Jul 17, 2018 at 12:07:10PM +0200, Michael Van Canneyt wrote:
> >On Tue, Jul 17, 2018 at 11:14:31AM +0200, Michael Van Canneyt wrote:
> If you need to "reduce the scope of variables", your routines are too long to
> begin with.
> 
> If of course you write routines of several hundreds of lines (or thousands),
> then you probably would need to have such a feature.
> 
> But I would fire any programmer that writes such code anyway, since it
> indicates he cannot think structured.

And I'd fire any programmer that doesn't properly scope their variables,
just as you'd (hopefully) fire a programmer for using global instead of
function level variables.

> But probably this whole answer is again too hyperbole :-)

It's not the hyperbole that really worries me too much, I like a bit of
that myself.  I'm worried about the knee-jerk reactions to good ideas.
Badly written responses like "reduces readability" is extremely
uncharitable without proper motivation and projects the image that
everyone on this list will just shoot down any improvement to their
beloved Pascal.

Anyway, not much to add to the subject without repeating myself.

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

Re: [fpc-pascal] Syntax changes suggestions

[Michael Van Canneyt]

On Tue, 17 Jul 2018, Henry Vermaak wrote:


On Tue, Jul 17, 2018 at 12:07:42PM +0200, Martin wrote:

On 17/07/2018 12:02, Henry Vermaak wrote:
>On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
>>*you* might do this, but there are enough developers that won't. I
>>already
>By not having this feature you're not giving anyone a choice.
>
By having this feature you are forcing everyone to use it.


No, why would you think that?  Nobody is forcing you to move your
variables into a block, just carry on as before if you don't like it.
Var sections for functions are optional, you can use global variables
for everything if you like.  No different to this.


The point under discussion is readability of code.

So, if I need to read someone elses code and this person uses this feature heavily, 
then I end up being confronted with it, the readability of his code for me

is reduced.

Pascal has always been lauded for being readable. 
I would like to keep it that way.


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

Re: [fpc-pascal] Syntax changes suggestions

[Martin]

On 17/07/2018 11:05, Henry Vermaak wrote:

On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:

Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:


I have some suggestions of change to freepascal syntax, just to debate

(All are backward compatible)

- Declaring variables inside blocks, and loop variables


-> reduces readability -> no interest

How can it reduce readability?  You move variables closer to where they
are used, therefore reducing clutter in the main "var" section.
Limiting variable scope is definitely a good thing, I sure hope you're
not arguing against that.  That's why almost all languages encourage it.


On the contra side:

You could then have 2 or more differnt "i" variables in one procedure. 
That is hell to read.


Of course you could argue that you can only have a "nested" "i", if 
there is no local var "i" (current style local). And no other nesting.

Still 2 issues:
You could have 2 consecutive loops, with different typed "i". That can 
be confusing. (it may not be to you, but is still can be). Now you would 
need 2 different named loop counters (which to me is good).


But more troubling:
You do no longer have a complete list of all local vars. That means, if 
I want to add a (current style) local var "i", i may have to scan the 
entire procedure (maybe hundreds of lines) to find if there already is a 
nested "i" (or start the compiler to see if there is an error).
That would be a real burden added to pascal (and since I may have to 
work on other peoples code, it is no good to say that I could simply not 
use it)


--
Also lets make a distinction here:

What are we looking for:
A) Saving the (so called) work, of declaring the var on top? (Note: that 
the work is pressing ctrl-shift-c)?

B) Introducing vars with more fine grained scoping?

As for (A) I already expressed that I am against it. (there also is a 
recent thread on the forum where this was discussed, so look it up and 
read the arguments)


As for (B):
I don't know of any good proposal, but if there was it would have to be 
something like this: (I still dont like it, but if there was a good idea 
to bring it in shape...)


procedure Foo;
var
   a: Integer; // normal vor
scoped var
   b: integer;
begin
  //b can not be used here / it will be as if it does not exist
  a := bar();
  if a > 1 then begin
    scope b;  // must be first after begin
    b := 1;
  end;
  // b out of scope
  // scope for one statement (the entire for, including the begin end 
which as a compound statement is part of the for.

  with scope b do for b := 1 to 10 do ... ;
// alternatively
  using scope b do for b := 1 to 10 do ... ;
  scope b: for b := 1 to 10 do ... ;

So you still declare the var on top.

Again, this is to entertain an idea, which I personally do not like

If you have a scoping problem in pascal, cut your code into smaller 
procedures.


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

Re: [fpc-pascal] Syntax changes suggestions

[Henry Vermaak]

On Tue, Jul 17, 2018 at 12:07:42PM +0200, Martin wrote:
> On 17/07/2018 12:02, Henry Vermaak wrote:
> >On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
> >>*you* might do this, but there are enough developers that won't. I
> >>already
> >By not having this feature you're not giving anyone a choice.
> >
> By having this feature you are forcing everyone to use it.

No, why would you think that?  Nobody is forcing you to move your
variables into a block, just carry on as before if you don't like it.
Var sections for functions are optional, you can use global variables
for everything if you like.  No different to this.

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

Re: [fpc-pascal] Syntax changes suggestions

[Michael Van Canneyt]

On Tue, 17 Jul 2018, Martin wrote:


On 17/07/2018 12:02, Henry Vermaak wrote:

On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
*you* might do this, but there are enough developers that won't. I 
already 

By not having this feature you're not giving anyone a choice.


By having this feature you are forcing everyone to use it.

(This has been explained plenty of times)


Exactly.

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

Re: [fpc-pascal] Syntax changes suggestions

[Martin]

On 17/07/2018 12:02, Henry Vermaak wrote:

On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
*you* might do this, but there are enough developers that won't. I 
already 

By not having this feature you're not giving anyone a choice.


By having this feature you are forcing everyone to use it.

(This has been explained plenty of times)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Michael Van Canneyt]

On Tue, 17 Jul 2018, Henry Vermaak wrote:


On Tue, Jul 17, 2018 at 11:14:31AM +0200, Michael Van Canneyt wrote:

On Tue, 17 Jul 2018, Henry Vermaak wrote:
>On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
>>Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:
>>
>>> I have some suggestions of change to freepascal syntax, just to debate
>>>
>>> (All are backward compatible)
>>>
>>> - Declaring variables inside blocks, and loop variables
>>>
>>-> reduces readability -> no interest
>
>How can it reduce readability?  You move variables closer to where they
>are used, therefore reducing clutter in the main "var" section.

Pascal separates declaration from implementation. This proposal changes
that, it mixes implementation with declaration.


No, it will still separate the declaration, but just on the block level.


You are still mixing code with declarations.


When you look for a variable, you know it is in the declaration block.
If you need to start scanning the code, this is a major nuisance.


If you're in a block, you look at the "var" section of the block first,
then move up a block and repeat.  Calling it "a major nuisance" is
needless hyperbole.


I like hyperbole, one can never have too much hyperbole :)


In the above code, why do I want to see foo in the
main "var" block of the function?  It's just noise there, reducing
readability.


Of course not, that's where it belongs.


I can't count the misunderstandings in Javascript due to this 'feature'.


This feature makes you properly reduce scope of variables, I seriously
haven't met anyone that thinks this is a bad idea.  It's standard
programming practise in every language I've worked.


If you need to "reduce the scope of variables", your routines are too long to
begin with.

If of course you write routines of several hundreds of lines (or thousands),
then you probably would need to have such a feature.

But I would fire any programmer that writes such code anyway, 
since it indicates he cannot think structured.


But probably this whole answer is again too hyperbole :-)

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

Re: [fpc-pascal] Syntax changes suggestions

[Henry Vermaak]

On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
> Henry Vermaak  schrieb am Di., 17. Juli 2018,
> 11:05:
> 
> > On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> > > Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:
> > >
> > > > I have some suggestions of change to freepascal syntax, just to debate
> > > >
> > > > (All are backward compatible)
> > > >
> > > > - Declaring variables inside blocks, and loop variables
> > > >
> > > -> reduces readability -> no interest
> >
> > How can it reduce readability?  You move variables closer to where they
> > are used, therefore reducing clutter in the main "var" section.
> >
> 
> *you* might do this, but there are enough developers that won't. I already

By not having this feature you're not giving anyone a choice.

> don't like looking at such C code, so why would I want that in Pascal which
> avoided that problem?

What problem?  I'm not saying I want to mix declarations with code, the
var section should be at the top of the block/scope.  I don't even know
any C programmers that mix declarations with code.  This isn't the 80s.

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

Re: [fpc-pascal] Syntax changes suggestions

[Sven Barth via fpc-pascal]

Henry Vermaak  schrieb am Di., 17. Juli 2018,
11:05:

> On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> > Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:
> >
> > > I have some suggestions of change to freepascal syntax, just to debate
> > >
> > > (All are backward compatible)
> > >
> > > - Declaring variables inside blocks, and loop variables
> > >
> > -> reduces readability -> no interest
>
> How can it reduce readability?  You move variables closer to where they
> are used, therefore reducing clutter in the main "var" section.
>

*you* might do this, but there are enough developers that won't. I already
don't like looking at such C code, so why would I want that in Pascal which
avoided that problem?

Limiting variable scope is definitely a good thing, I sure hope you're
> not arguing against that.  That's why almost all languages encourage it.
>

I'm arguing against micromanaging the scope of a variable inside a
function.

Regards,
Sven

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

Re: [fpc-pascal] Syntax changes suggestions

[Henry Vermaak]

On Tue, Jul 17, 2018 at 11:14:31AM +0200, Michael Van Canneyt wrote:
> On Tue, 17 Jul 2018, Henry Vermaak wrote:
> >On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> >>Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:
> >>
> >>> I have some suggestions of change to freepascal syntax, just to debate
> >>>
> >>> (All are backward compatible)
> >>>
> >>> - Declaring variables inside blocks, and loop variables
> >>>
> >>-> reduces readability -> no interest
> >
> >How can it reduce readability?  You move variables closer to where they
> >are used, therefore reducing clutter in the main "var" section.
> 
> Pascal separates declaration from implementation. This proposal changes
> that, it mixes implementation with declaration.

No, it will still separate the declaration, but just on the block level.
For example:

for i := 0 to n - 1 do
var
  foo: integer = 0;
begin
  // ...
end;

> When you look for a variable, you know it is in the declaration block.
> If you need to start scanning the code, this is a major nuisance.

If you're in a block, you look at the "var" section of the block first,
then move up a block and repeat.  Calling it "a major nuisance" is
needless hyperbole.  In the above code, why do I want to see foo in the
main "var" block of the function?  It's just noise there, reducing
readability.

> I can't count the misunderstandings in Javascript due to this 'feature'.

This feature makes you properly reduce scope of variables, I seriously
haven't met anyone that thinks this is a bad idea.  It's standard
programming practise in every language I've worked.

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

Re: [fpc-pascal] Syntax changes suggestions

[Mark Morgan Lloyd]

On 17/07/18 09:15, Henry Vermaak wrote:

On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:> Santiago A.  schrieb am Mo., 
16. Juli 2018, 13:41:> > > I have some suggestions of change to freepascal syntax, just to debate> >> > (All are 
backward compatible)> >> > - Declaring variables inside blocks, and loop variables> >> -> reduces readability 
-> no interest
How can it reduce readability?  You move variables closer to where theyare used, 
therefore reducing clutter in the main "var" section.Limiting variable scope is 
definitely a good thing, I sure hope you'renot arguing against that.  That's why almost 
all languages encourage it.


Agreed, and that's /particularly/ the case with something like a loop 
control variable which should not be assumed to have a predictable value 
out-of-scope.


Wirth moved variables outside blocks to make Pascal incompatible with 
ALGOL, since after the disastrous ALGOL-68 fiasco he wanted to plough 
his own furrow. That doesn't necessarily make the decision a wise one.


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

Re: [fpc-pascal] Syntax changes suggestions

[Michael Van Canneyt]

On Tue, 17 Jul 2018, Henry Vermaak wrote:


On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:

Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:

> I have some suggestions of change to freepascal syntax, just to debate
>
> (All are backward compatible)
>
> - Declaring variables inside blocks, and loop variables
>
-> reduces readability -> no interest


How can it reduce readability?  You move variables closer to where they
are used, therefore reducing clutter in the main "var" section.


Pascal separates declaration from implementation. 
This proposal changes that, it mixes implementation with declaration.


When you look for a variable, you know it is in the declaration block.
If you need to start scanning the code, this is a major nuisance.
I can't count the misunderstandings in Javascript due to this 'feature'.

Given that the length a typical routine should not exceed 50 lines 
- i.e. fits on a modern screen - you can :

a) not have too many variables anyway.
b) see them at the glance of an eye at the top of your screen.

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

Re: [fpc-pascal] Syntax changes suggestions

[Henry Vermaak]

On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:
> 
> > I have some suggestions of change to freepascal syntax, just to debate
> >
> > (All are backward compatible)
> >
> > - Declaring variables inside blocks, and loop variables
> >
> -> reduces readability -> no interest

How can it reduce readability?  You move variables closer to where they
are used, therefore reducing clutter in the main "var" section.
Limiting variable scope is definitely a good thing, I sure hope you're
not arguing against that.  That's why almost all languages encourage it.

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

Re: [fpc-pascal] Syntax changes suggestions

[Marco van de Voort]

In our previous episode, Santiago A. said:
> > And since the feature is implementable as an IDE macro (generating a nested
> > try except/finally) it doesn't make Ooccam's razor of usefulness to begin
> > with.
> The Occam's razor is that if it is so usefull that a macro is used a 
> lot, why not make it part of the languages avoiding depending on 
> external tools?

Because, like Sven said, there is a lot of crosstalk and fallout with a
language feature, and the IDE macro is limited to the handful of people that
for some reason have a high occurance of the feature in their business code
architecture.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Santiago A.]

El 17/07/2018 a las 10:11, Marco van de Voort escribió:

In our previous episode, Sven Barth via fpc-pascal said:

interested in why it is not supported.

At least Delphi Tokyo (10.2) does not support it.

If I remember the discussion correctly it came to light that some users
would need "try ? finally ? except ? end" while others would need "try ?
except ? finally ? end" and even some "try ? finally ? except ? finally
? end" or the like. With differences in opinion like this the idea was
dropped, cause this flexibility exists already, namely by using separate
blocks.

And since the feature is implementable as an IDE macro (generating a nested
try except/finally) it doesn't make Ooccam's razor of usefulness to begin
with.
The Occam's razor is that if it is so usefull that a macro is used a 
lot, why not make it part of the languages avoiding depending on 
external tools?


--
Saludos

Santiago A.

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

Re: [fpc-pascal] Syntax changes suggestions

[Santiago A.]

El 16/07/2018 a las 21:27, Marco van de Voort escribió:

In our previous episode, Sven Barth via fpc-pascal said:

function)

In such cases, you don't declare it "auto". Just as you don't free a
pointer in the function you declare it if you pass the instance to another
code that stores it beyond the life time of the function


But you don't necessarily know that the function you call does that (think
third party code). And people *will* use this and don't think about the
consequences. So a system with automatic reference counting is safer and
that is what is planned, if at all.

Moreover the use case, dynamically instantiated classes with very local
scope is rare.
You must be kidding. You use local scope objects everywhere. The 
TStreams family is a clear example.


source/rtl/objpas/classes/classes.inc

//
function CollectionsEqual(C1, C2: TCollection; Owner1, Owner2: 
TComponent): Boolean;


  procedure stream_collection(s : tstream;c : tcollection;o : tcomponent);
    var
  w : twriter;
    begin
  w:=twriter.create(s,4096);
  try
    w.root:=o;
    w.flookuproot:=o;
    w.writecollection(c);
  finally
    w.free;
  end;
    end;

  var
    s1,s2 : tmemorystream;
  begin
    result:=false;
    if (c1.classtype<>c2.classtype) or
  (c1.count<>c2.count) then
  exit;
    if c1.count = 0 then
  begin
  result:= true;
  exit;
  end;
    s1:=tmemorystream.create;
    try
  s2:=tmemorystream.create;
  try
    stream_collection(s1,c1,owner1);
    stream_collection(s2,c2,owner2);
    result:=(s1.size=s2.size) and 
(CompareChar(s1.memory^,s2.memory^,s1.size)=0);

  finally
    s2.free;
  end;
    finally
  s1.free;
    end;
  end;


//
// auto version
//

function CollectionsEqual(C1, C2: TCollection; Owner1, Owner2: 
TComponent): Boolean;


  procedure stream_collection(s : tstream;c : tcollection;o : tcomponent);
    var
  w : twriter;auto;
    begin
  w:=twriter.create(s,4096);
 w.flookuproot:=o;
  w.writecollection(c);
    end;

  var
    s1,s2 : tmemorystream; auto;
  begin
    result:=false;
    if (c1.classtype<>c2.classtype) or
  (c1.count<>c2.count) then
  exit;
    if c1.count = 0 then
  begin
  result:= true;
  exit;
  end;
    s1:=tmemorystream.create;
    s2:=tmemorystream.create;
   stream_collection(s1,c1,owner1);
    stream_collection(s2,c2,owner2);
    result:=(s1.size=s2.size) and 
(CompareChar(s1.memory^,s2.memory^,s1.size)=0);

  end;
//

With "Auto", you save a lot of "try finally free" that add nothing to 
algorithm


You can argue against "auto" in the grounds of "Aesthetic symmetry ", 
"it's not explicitness pascal way", "it's not worth", "confusion mixing 
styles/paradigms" or other arguments I haven't thought. I asked 
expecting those arguments I hadn't thought about.
There may be valid arguments against, but when I read "local scope for 
classes is rare", I know I am in the grounds of a irrational 
resistance.  In such cases, a "For the sake of brevity, my vote is 
simply "no" to all your suggestions." is the best answer.


--
Saludos

Santiago A.

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

Re: [fpc-pascal] Syntax changes suggestions

[Marco van de Voort]

In our previous episode, Sven Barth via fpc-pascal said:
> > interested in why it is not supported.
> 
> At least Delphi Tokyo (10.2) does not support it.
> 
> If I remember the discussion correctly it came to light that some users 
> would need "try ? finally ? except ? end" while others would need "try ? 
> except ? finally ? end" and even some "try ? finally ? except ? finally 
> ? end" or the like. With differences in opinion like this the idea was 
> dropped, cause this flexibility exists already, namely by using separate 
> blocks.

And since the feature is implementable as an IDE macro (generating a nested
try except/finally) it doesn't make Ooccam's razor of usefulness to begin
with.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[el_es]

On 17/07/18 06:16, Sven Barth via fpc-pascal wrote:
> Am 16.07.2018 um 23:14 schrieb R0b0t1:
>> On Mon, Jul 16, 2018 at 3:28 PM, Sven Barth via fpc-pascal 
>>  wrote:
>>> Am 16.07.2018 um 19:55 schrieb R0b0t1:
 
> - Try except finally blocks
 I can support this one, I am surprised it is not already
 supported. Wasn't this mentioned in another recent thread as
 existing? Does it exist in at least Delphi mode?
>>> 
>>> This is not supported and the last time it was discussed here on
>>> the mailing lists it was shot down (though I can't find the
>>> thread currently...). Also why should it exist in Delphi mode
>>> when Delphi does not support it? (Yes, there are some features
>>> that work in Delphi mode that Delphi doesn't support, but in
>>> generic the purpose of mode Delphi is to support Delphi code)
>> From my searching it is in (newer?) Delphi. I can't admit to being
>> a huge fan of "finally" (I don't typically use it myself) but I am 
>> interested in why it is not supported.
> 
> At least Delphi Tokyo (10.2) does not support it.
> 
> If I remember the discussion correctly it came to light that some
> users would need "try … finally … except … end" while others would
> need "try … except … finally … end" and even some "try … finally …
> except … finally … end" or the like. With differences in opinion like
> this the idea was dropped, cause this flexibility exists already,
> namely by using separate blocks.
> 
> Regards, Sven 

I just had an idea come to my head - what if Lazarus would handle
the tiers of try for us ? Maybe it should be a feature of the code editor,
to convert

try
  try
try
  code block 1;
except
  code block 2;
end;
  finally
code block 3;
  end;
except
  code block 4;
end;

into 

try
  code block 1;
except
  code block 2; 
finally
  code block 3;
except
  code block 4
end;

and variations thereof; Then no compiler changes are necessary.

Lazarus already has the 'collapsible code blocks', and this is not much
different. I'll post this idea to Lazarus list.

cheers,
el es

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