[fpc-pascal] Syntax changes suggestions

[Santiago A.]

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

(All are backward compatible)

- Declaring variables inside blocks, and loop variables
- Autofree pointers
- Try except finally blocks
- Private declarations in implementation

some of them can be found in
https://www.codeproject.com/Articles/1252167/Delphi-Language-Progression-Suggestions

**declaring variables inside blocks, and loop variables**

var
 Number1,number2:Integer;
 f:textFile;
begin
  <...>
  while not eof(f) do begin
     Readln(f,number1,number2);
     if number1>number2 then
       begin
         var swapnum:Integer;// declaring in a block. Even initializing
it, var swapnum:Integer:=Number1;
         swapnum:=number1;
         number1:=number2;
         number2:=swapnum;
       end;
  end;
  <...>
end;

---------------

for var i:integer:=1 to 100 do
   begin
      <...>
   end;

---------------

**autofree pointers**

procedure foo;
  var s:TStringList; auto;// you add "auto", like absolute
begin
  s:=TStringList.create;
  <..>
  // s is freed automaticallyat the end of block, without try finally
end;

That combined with declaring inside blocks would make things less
verbose avoiding a lot of try finally.

**try except finally blocks**

instead of

------------------
 try
    try
      <...>
    except
       <...>
    end;
 finally
    <...>
 end;
------------------

just write

------------------
 try
    <...>
 except
    <...>
 finally
    <...>
 end;

**Private declarations in implementation**

In the implementation, being able to implement a private method without
declaring it in the interface part.
You just write:

-------------------------
implementation

procedure TMyClass.MyPrivateMethod;
begin
  <...>
end;
-------------------------

And if it is not declared in the interface part, it is assumed as private.
It is a private method, nobody is aware of it outside of the
implementation, it can't be used in derived classes, it unnecessary in
the interface, and needn't to be declared.

The same could be applied for private vars. :

--------------------------
implementation

var
 TMyClass.privateVar: Integer;
--------------------------

I suppose this is more difficult with variables than with methods,
because of reserving memory etc, but it would be handy.

--
Saludos

Santiago A.

[Michael Fuchs]

Am 16.07.2018 um 13:40 schrieb Santiago A.:
> for var i:integer:=1 to 100 do
>    begin
>       <...>
>    end;

What is the benefit? Poorer readability?

g
Michael
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://

[Michael Van Canneyt]

On Mon, 16 Jul 2018, Santiago A. wrote:

> I have some suggestions of change to freepascal syntax, just to debate
>
> (All are backward compatible)
>
> - Declaring variables inside blocks, and loop variables
> - Autofree pointers
> - Try except finally blocks
> - Private declarations in implementation
>
> some of them can be found in
> https://www.codeproject.com/Articles/1252167/Delphi-Language-Progression-Suggestions

Some can be considered regressions, not progression.

autofree pointers will be available with management operators, I suppose.
probably try except finally blocks is still doable.

But declaring variables inside code blocks makes for really bad readability
and - worse - possibly error prone code.

What to do with scope rules ?

Var
C : integer;

begin
C:=1; // C is integer
// New block, hence new scope
for var c:string in List do begin
... // C is string
end;

Which is IMO error prone.

the alternative is the javascript way, elevate the "c" in the for loop to a
procedure local variable, in which case the above should result in an error,
and which is a major source of problems.

Either way, I don't think this is very desirable.

Michael.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists

[Santiago A.]

El 16/07/2018 a las 13:59, Michael Van Canneyt escribió:
>
>
> On Mon, 16 Jul 2018, Santiago A. wrote:
>
>> I have some suggestions of change to freepascal syntax, just to debate
>>
>> (All are backward compatible)
>>
>> - Declaring variables inside blocks, and loop variables
>> - Autofree pointers
>> - Try except finally blocks
>> - Private declarations in implementation
>>
>> some of them can be found in
>> https://www.codeproject.com/Articles/1252167/Delphi-Language-Progression-Suggestions
>
> Some can be considered regressions, not progression.
>
> autofree pointers will be available with management operators, I suppose.
> probably try except finally blocks is still doable.
>
> But declaring variables inside code blocks makes for really bad
> readability and - worse - possibly error prone code.
>
> What to do with scope rules ?
>
> Var
>   C : integer;
>
> begin
>   C:=1; // C is integer
>   // New block, hence new scope
>   for var c:string in List do begin
>     ... // C is string
>   end;

It is a local variable to the block, the scope is the from the
declaration to the end of the block. Nevertheless, I think that
declarations should be at the beginning of the block, before any
executable statement, so the scope is the block.
Ada, has the structure
-------------
if  a>b then
   Declare
     s:string='aaaa';
begin
      <...>
end;
end if;
--------------

I just say that the nearer the variable to the place you use it, the
better. Particularly in the case of FOR loops it makes a lot of sense.
In fact, the variable shouldn't make sense before or after the loop. Why
not declare it just in the loop? Ada does it.

I don't think Ada is a language of dirty hacks.

--
Saludos

Santiago A.

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org

[Martin]

On 16/07/2018 16:46, Santiago A. wrote:
> El 16/07/2018 a las 13:59, Michael Van Canneyt escribió:
>>
>> But declaring variables inside code blocks makes for really bad
>> readability and - worse - possibly error prone code.
>>
>> What to do with scope rules ?
>>
>> Var
>>   C : integer;
>>
>> begin
>>   C:=1; // C is integer
>>   // New block, hence new scope
>>   for var c:string in List do begin
>>     ... // C is string
>>   end;
>
> It is a local variable to the block, the scope is the from the
> declaration to the end of the block.
What is a block?
a) Each individual statement
b) a compound statement

** if a, then your examble
   begin
      var a: integer;  // statement ends at ";" the scope ends too
      foobar;

** if b:
Var
  C : integer;

begin // <<<<<<<<<< block "1" begins here
  C:=1; // C is integer
  // New block, hence new scope // <<<<<<<<<<<< see question above,
where exactly is the new block?
  for var c:string in List do begin // <<<<<<<<<< block "2" begins
after/with the "begin" statement
    ... // C is string
  end;

var c:string is therefore part of block 1. And valid to the end of block
1, which includes the code after the loop.



> Nevertheless, I think that declarations should be at the beginning of
> the block, before any executable statement, so the scope is the block.

well in your "for" loop example, that is not the case. the "var" is not
at the start of the block. (whatever the block is).

So you already contradict yourself.

Besides that, the discussion has been had plenty of times already, most
recently on the forum.
So the question is not "why this feature", but "what makes this instance
of the discussion different"?

And please do not say "if it is requested so many times", because if
this was to be an argument, then I could request a million times to
replace "begin" with "{", but at the same time keep "end" as keyword. If
I request it often enough, it would have to be good, or would it not?



_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/

[Anthony Walter]

To the OP:

For the sake of brevity, my vote is simply "no" to all your suggestions.

[Ralf Quint]

On 7/16/2018 8:36 AM, Anthony Walter wrote:
> To the OP:
>
> For the sake of brevity, my vote is simply "no" to all your suggestions.
+1



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Sven Barth via fpc-pascal]

Santiago A. <***@ciberpiula.net> 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

- Autofree pointers
>
Might come, though not in that way (take your example: what if you pass the
instance to some other code that stores it beyond the life time of the
function)

- Try except finally blocks
>
This had been proposed some time ago and was declined after quite some
discussion (either here or on fpc-devel).

- Private declarations in implementation
>
Again this reduces readability and thus no interest.

Regards,
Sven

[Santiago A.]

El 16/07/2018 a las 15:02, Sven Barth via fpc-pascal escribió:
> Santiago A. <***@ciberpiula.net <mailto:***@ciberpiula.net>> 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
I think the opposite.
The nearer the declaration to the code where you use it, the better.

>
> - Autofree pointers
>
> Might come, though not in that way (take your example: what if you
> pass the instance to some other code that stores it beyond the life
> time of the 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

>
> - Try except finally blocks
>
> This had been proposed some time ago and was declined after quite some
> discussion (either here or on fpc-devel).
>
> - Private declarations in implementation
>
> Again this reduces readability and thus no interest.

Once again, I think the opposite.
It's not very readable a class where you have to skim through 100 lines
of private declaration that you don't care, because you can do nothing
with them.

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


--
Saludos

Santiago A.

[Sven Barth via fpc-pascal]

Santiago A. <***@ciberpiula.net> schrieb am Mo., 16. Juli 2018, 16:27:

> El 16/07/2018 a las 15:02, Sven Barth via fpc-pascal escribió:
>
> Santiago A. <***@ciberpiula.net> 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
>
> I think the opposite.
> The nearer the declaration to the code where you use it, the better.
>

I disagree. The way it is in Pascal you can easily see which variables are
used and what type they have while with inline declarations you need to
skim the whole routine. And trust me, only because a variable *can* be
declared close to its use it does not mean that it *is*.


>
> - Autofree pointers
>>
> Might come, though not in that way (take your example: what if you pass
> the instance to some other code that stores it beyond the life time of the
> 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.


>
> - Try except finally blocks
>>
> This had been proposed some time ago and was declined after quite some
> discussion (either here or on fpc-devel).
>
> - Private declarations in implementation
>>
> Again this reduces readability and thus no interest.
>
>
> Once again, I think the opposite.
> It's not very readable a class where you have to skim through 100 lines of
> private declaration that you don't care, because you can do nothing with
> them.
>

Again all the declarations reside in one place currently, namely the
declaration of the class. With your idea I'd have to search the whole unit
not to mention that the order of declaration would be important as well
just like it had been in procedural Pascal due to the single pass nature of
the language.

Regards,
Sven

>

[Ryan Joseph]

> On Jul 16, 2018, at 8:27 AM, Santiago A. <***@ciberpiula.net> wrote:
>
>> - Autofree pointers
>>
>> Might come, though not in that way (take your example: what if you pass the instance to some other code that stores it beyond the life time of the function)
> In such cases, you don't declare it "auto".

Yes exactly!!!!


Regards,
Ryan Joseph

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

[Ryan Joseph]

> On Jul 16, 2018, at 7:02 AM, Sven Barth via fpc-pascal <fpc-***@lists.freepascal.org> wrote:
>
> Might come, though not in that way (take your example: what if you pass the instance to some other code that stores it beyond the life time of the function)

That’s what you guys said about my awesome “stack alias” idea. :) Seriously though I don’t for the life of me understand why programmers can’t be trusted to not do this. You can pass dangling pointers since forever but no one is asking pointers to be removed because they’re too dangerous.

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.

Regards,
Ryan Joseph

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.or

[Sven Barth via fpc-pascal]

Am 17.07.2018 um 04:48 schrieb Ryan Joseph:
>
>> On Jul 16, 2018, at 7:02 AM, Sven Barth via fpc-pascal <fpc-***@lists.freepascal.org> wrote:
>>
>> Might come, though not in that way (take your example: what if you pass the instance to some other code that stores it beyond the life time of the function)
> That’s what you guys said about my awesome “stack alias” idea. :) Seriously though I don’t for the life of me understand why programmers can’t be trusted to not do this. You can pass dangling pointers since forever but no one is asking pointers to be removed because they’re too dangerous.
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.

Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bi

[Ryan Joseph]

> On Jul 16, 2018, at 11:20 PM, Sven Barth via fpc-pascal <fpc-***@lists.freepascal.org> 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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/

[Henry Vermaak]

On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> Santiago A. <***@ciberpiula.net> 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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-b

[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. <***@ciberpiula.net> 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-***@lists.freepascal.org
http://lists.freepasca

[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. <***@ciberpiula.net> 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-***@lists.freepascal.org
http://lists.freepasc

[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. <***@ciberpiula.net> 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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mail

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

[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-***@lists.freepascal.org
http://lis

[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 <***@freepascal.org>
> Komu: FPC-Pascal users discussions <fpc-***@lists.freepascal.org>
> 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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal <http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal>

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

[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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/m

[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 <***@freepascal.org>
> Komu: FPC-Pascal users discussions <fpc-***@lists.freepascal.org>
> 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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal <http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal>

[Florian Klaempfl]

Am 17.07.2018 um 12:07 schrieb Michael Van Canneyt:
> 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.
>

You should fire the whole compiler development team then ;)

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/ma

[Henry Vermaak]

On Tue, Jul 17, 2018 at 09:32:24AM +0000, Mark Morgan Lloyd wrote:
> 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. <***@ciberpiula.net> 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.

Spot on, you can pretty much eliminate that class of bug with this.

Henry
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/ma

[Sven Barth via fpc-pascal]

Henry Vermaak <***@gmail.com> 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. <***@ciberpiula.net> 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

>

[Henry Vermaak]

On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
> Henry Vermaak <***@gmail.com> 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. <***@ciberpiula.net> 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-***@lists.freepascal.org
http://lists.

[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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mai

[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-***@lists.freepascal.org
http://lists.freepascal.or

[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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/ma

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

[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. <***@ciberpiula.net> 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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin

[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. <***@ciberpiula.net> 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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pasca

[Reimar Grabowski]

On Tue, 17 Jul 2018 12:04:19 +0200
Martin <***@mfriebe.de> 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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/

[R0b0t1]

On Mon, Jul 16, 2018 at 6:40 AM, Santiago A. <***@ciberpiula.net> wrote:
> I have some suggestions of change to freepascal syntax, just to debate
>
> (All are backward compatible)
>
> - Declaring variables inside blocks, and loop variables

Declarations inside blocks I am unable to support. Declarations as
loops I *might* be able to support, but once you go from a C-like
language to Pascal and get used to predeclaring variables it starts to
become nice. You don't have to figure out where things are.

> - Autofree pointers

Useful but it looks like this will not be a base language feature.

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

> - Private declarations in implementation
>

Typically you should "hide" things in either a private class method or
in method variables.


FPC is already lacking in some major ways compared to Delphi. The main
one I can think of is anonymous functions. If anyone could implement
that the community would benefit immensely.

I've looked, on and off, but not been able to make a lot of progress.

Cheers,
R0b0t1
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinf

[Sven Barth via fpc-pascal]

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)
> FPC is already lacking in some major ways compared to Delphi. The main
> one I can think of is anonymous functions. If anyone could implement
> that the community would benefit immensely.

As I had already written you on the Forum ( http://forum.lazarus.freepascal.org/index.php/topic,39051.msg269034.html#msg269034 ) this is WIP and you could help the author if you wanted.

Regards,
Sven

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepa

[R0b0t1]

On Mon, Jul 16, 2018 at 3:28 PM, Sven Barth via fpc-pascal
<fpc-***@lists.freepascal.org> 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.

>>
>> FPC is already lacking in some major ways compared to Delphi. The main
>> one I can think of is anonymous functions. If anyone could implement
>> that the community would benefit immensely.
>
>
> As I had already written you on the Forum (
> http://forum.lazarus.freepascal.org/index.php/topic,39051.msg269034.html#msg269034
> ) this is WIP and you could help the author if you wanted.
>

My apologies, I think I stopped checking the forum as regularly before
you posted. I will look for the code.

Cheers,
R0b0t1
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/l

[Sven Barth via fpc-pascal]

Am 16.07.2018 um 23:14 schrieb R0b0t1:
> On Mon, Jul 16, 2018 at 3:28 PM, Sven Barth via fpc-pascal
> <fpc-***@lists.freepascal.org> 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
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc

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

[Ryan Joseph]

> On Jul 16, 2018, at 11:55 AM, R0b0t1 <***@gmail.com> wrote:
>
> Declarations inside blocks I am unable to support. Declarations as
> loops I *might* be able to support, but once you go from a C-like
> language to Pascal and get used to predeclaring variables it starts to
> become nice. You don't have to figure out where things are.

but isn’t “i” for loops an exception? I have i:integer; in so many places in my code it’s safe to assume at this point what I want.

Regards,
Ryan Joseph

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.fre

[Marco van de Voort]

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

[Ryan Joseph]

> On Jul 16, 2018, at 1:27 PM, Marco van de Voort <***@stack.nl> wrote:
>
>> 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.

1) if you call a function that has an “auto” variable how does that affect the caller? I don’t see how it could.

2) Huh? I always allocate classes in functions. All the time. I do it so often I want a language feature to do clean up for me. This is also a way to deallocate classes with auto members so you don’t need to override the destructor all the time.

c++ does this using classes on the stack and it’s ubiquitous. In FPC we need to allocate the memory and call free every single time, even in local scope when we know we don’t need the class anymore. It’s such an obvious feature I don’t understand how it gets so much resistance.

Regards,
Ryan Joseph

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.or

[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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mai

[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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listin

[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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/

[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-***@lists.freepascal.org
http://lists.freepascal.org/

[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-***@lists.freepascal.org
http://li

[Sven Barth via fpc-pascal]

Marco van de Voort <***@stack.nl> 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

>

[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-***@lists.freepascal.org
http://lists.fre

[Ryan Joseph]

> On Jul 17, 2018, at 11:27 AM, Jim Lee <***@gmail.com> 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-***@lists.freepascal.org
http://lists.freepascal

[Jim Lee]

On 07/17/18 11:00, Ryan Joseph wrote:
>
>> On Jul 17, 2018, at 11:27 AM, Jim Lee <***@gmail.com> 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-***@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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/ma

[Ryan Joseph]

> On Jul 17, 2018, at 12:24 PM, Jim Lee <***@gmail.com> 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-***@lists.freepascal.org
http://l

[Jim Lee]

On 07/17/18 11:50, Ryan Joseph wrote:
>
>> On Jul 17, 2018, at 12:24 PM, Jim Lee <***@gmail.com> 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 <feature
of the day> to Pascal.

-Jim

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

[Ryan Joseph]

> On Jul 17, 2018, at 2:07 PM, Jim Lee <***@gmail.com> wrote:
>
> And that's why I hesitate whenever someone comes along and says we should add <feature of the day> 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-***@lists.freepascal.org
http://lists.freepascal.o

[Jim Lee]

On 07/17/18 13:28, Ryan Joseph wrote:
>
>> On Jul 17, 2018, at 2:07 PM, Jim Lee <***@gmail.com> wrote:
>>
>> And that's why I hesitate whenever someone comes along and says we should add <feature of the day> 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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/list

[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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/

[Dekks Herton]

Ryan Joseph <***@thealchemistguild.com> writes:

>> On Jul 17, 2018, at 2:07 PM, Jim Lee <***@gmail.com> wrote:
>>
>> And that's why I hesitate whenever someone comes along and says we should add <feature of the day> 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.

Thereby rests one of the problems of modern programming, choose the best
tool at hand for the project at hand. Trouble is so many only know 1 or
2 languages [looking at you java + python] people try to make them do
everything thus leading to half assed features + bloat.

--
Regards.........

PGP Fingerprint: 3DF8 311C 4740 B5BC 3867 72DF 1050 452F 9BCE BA00
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepasca

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

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

[Ryan Joseph]

> On Jul 17, 2018, at 2:15 PM, Sven Barth via fpc-pascal <fpc-***@lists.freepascal.org> 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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-p

[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 <fpc-***@lists.freepascal.org> 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-***@lists.freepascal.org
http://lists.freepasca

[Ryan Joseph]

> On Jul 17, 2018, at 2:41 PM, Sven Barth via fpc-pascal <fpc-***@lists.freepascal.org> wrote:
>
> 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.

that’s fair of course but what should be we do if we want to contribute? Remember I basically finished macros with parameters but what should I do now? The devs seemed to all really despise the idea but is there a formal channel I should use to petition for the idea or something? I heard from maybe5 people that said it was a stupid idea (fair enough) but what do the rest of the FPC users say?

Regards,
Ryan Joseph

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

[Sven Barth via fpc-pascal]

Ryan Joseph <***@thealchemistguild.com> schrieb am Mi., 18. Juli 2018,
19:15:

>
>
> > On Jul 17, 2018, at 2:41 PM, Sven Barth via fpc-pascal <
> fpc-***@lists.freepascal.org> wrote:
> >
> > 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.
>
> that’s fair of course but what should be we do if we want to contribute?
> Remember I basically finished macros with parameters but what should I do
> now? The devs seemed to all really despise the idea but is there a formal
> channel I should use to petition for the idea or something? I heard from
> maybe5 people that said it was a stupid idea (fair enough) but what do the
> rest of the FPC users say?
>

The devs have brought up reasons against the feature and you not accepting
or reasons against it is not a reason for us to accept your reasons for the
feature. And even if the majority of the users would be for the feature it
will always take someone to commit it and if none of the devs want your
feature than it won't be integrated. This is not a democracy.

And to give you a slightly different example: around a year ago or so I
implemented a IfThen() intrinsic that works like the if-statement, but as
an expression (like C's trinary ?: operator including not evaluating the
branch not taken). The majority of the users seemed to like it, but reasons
against it surfaced and so I reverted it again.

Regards,
Sven

>

[Ryan Joseph]

> On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal <fpc-***@lists.freepascal.org> wrote:
>
> And to give you a slightly different example: around a year ago or so I implemented a IfThen() intrinsic that works like the if-statement, but as an expression (like C's trinary ?: operator including not evaluating the branch not taken). The majority of the users seemed to like it, but reasons against it surfaced and so I reverted it again.
>

That’s pretty disheartening honestly. So there was a useful feature users could be leveraging but it was turned down because it didn’t fit into some paradigm or something like that. Sorry to hear that.

Since I’ve been using FPC in 2003-2004 the language has never forced any of its new features on me and I can still program Pascal like I did when I started in the 90’s. Forcing me to use features is where my line is crossed but I struggle to understand why we’re withholding good ideas from users to this extent.

Regards,
Ryan Joseph

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-b

[R0b0t1]

On Wed, Jul 18, 2018 at 2:04 PM, Ryan Joseph <***@thealchemistguild.com> wrote:
>
>
>> On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal <fpc-***@lists.freepascal.org> wrote:
>>
>> And to give you a slightly different example: around a year ago or so I implemented a IfThen() intrinsic that works like the if-statement, but as an expression (like C's trinary ?: operator including not evaluating the branch not taken). The majority of the users seemed to like it, but reasons against it surfaced and so I reverted it again.
>>
>
> That’s pretty disheartening honestly. So there was a useful feature users could be leveraging but it was turned down because it didn’t fit into some paradigm or something like that. Sorry to hear that.
>
> Since I’ve been using FPC in 2003-2004 the language has never forced any of its new features on me and I can still program Pascal like I did when I started in the 90’s. Forcing me to use features is where my line is crossed but I struggle to understand why we’re withholding good ideas from users to this extent.
>

You can make the function yourself. That you may have problems with
typing are indicative that the language could use a more expressive
type system, not that it was a good idea to create an intrinsic that
could (potentially) ignore types.

Cheers,
R0b0t1
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/l

[Ryan Joseph]

> On Jul 18, 2018, at 1:46 PM, R0b0t1 <***@gmail.com> wrote:
>
> You can make the function yourself. That you may have problems with
> typing are indicative that the language could use a more expressive
> type system, not that it was a good idea to create an intrinsic that
> could (potentially) ignore types.

I don’t remember what it did exactly. Like this maybe?

n = (x != 0) ? 10 : 20;

if x <> 0 then
n := 10
else
n := 20;

n := IfThen(x <> 0, 10, 20);

People are probably sick of doing that and wanted a more concise statement. I’ve even seen people do stuff like this because they’re fighting the language.

if x <> 0 then n := 10 else n := 20;

They probably wanted something like this:

n := if x <> 0 then 10 else 20;

Not too crazy in my opinion.

Regards,
Ryan Joseph

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://l

[Reimar Grabowski]

On Wed, 18 Jul 2018 14:33:51 -0600
Ryan Joseph <***@thealchemistguild.com> wrote:

> They probably wanted something like this:
>
> n := if x <> 0 then 10 else 20;
>
> Not too crazy in my opinion.

Only if you think that changing a statement to an expression is not 'too crazy'.
Btw in Kotlin if is an expression:

val n = if (x != 0) 10 else 20

But in pascal it's not and it's IMHO no small change to make it one.

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

[Sven Barth via fpc-pascal]

R0b0t1 <***@gmail.com> schrieb am Mi., 18. Juli 2018, 21:46:

> On Wed, Jul 18, 2018 at 2:04 PM, Ryan Joseph <***@thealchemistguild.com>
> wrote:
> >
> >
> >> On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal <
> fpc-***@lists.freepascal.org> wrote:
> >>
> >> And to give you a slightly different example: around a year ago or so I
> implemented a IfThen() intrinsic that works like the if-statement, but as
> an expression (like C's trinary ?: operator including not evaluating the
> branch not taken). The majority of the users seemed to like it, but reasons
> against it surfaced and so I reverted it again.
> >>
> >
> > That’s pretty disheartening honestly. So there was a useful feature
> users could be leveraging but it was turned down because it didn’t fit into
> some paradigm or something like that. Sorry to hear that.
> >
> > Since I’ve been using FPC in 2003-2004 the language has never forced any
> of its new features on me and I can still program Pascal like I did when I
> started in the 90’s. Forcing me to use features is where my line is crossed
> but I struggle to understand why we’re withholding good ideas from users to
> this extent.
> >
>
> You can make the function yourself.


You can't, because the main point of the intrinsic was that the parameter
that was in the branch not taken was not evaluated at all just like with
the if-statement. Normal function calls will always evaluate the
parameters.

Regards,
Sven

>

[R0b0t1]

On Wed, Jul 18, 2018 at 4:08 PM, Sven Barth via fpc-pascal
<fpc-***@lists.freepascal.org> wrote:
> R0b0t1 <***@gmail.com> schrieb am Mi., 18. Juli 2018, 21:46:
>>
>> On Wed, Jul 18, 2018 at 2:04 PM, Ryan Joseph <***@thealchemistguild.com>
>> wrote:
>> >
>> >
>> >> On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal
>> >> <fpc-***@lists.freepascal.org> wrote:
>> >>
>> >> And to give you a slightly different example: around a year ago or so I
>> >> implemented a IfThen() intrinsic that works like the if-statement, but as an
>> >> expression (like C's trinary ?: operator including not evaluating the branch
>> >> not taken). The majority of the users seemed to like it, but reasons against
>> >> it surfaced and so I reverted it again.
>> >>
>> >
>> > That’s pretty disheartening honestly. So there was a useful feature
>> > users could be leveraging but it was turned down because it didn’t fit into
>> > some paradigm or something like that. Sorry to hear that.
>> >
>> > Since I’ve been using FPC in 2003-2004 the language has never forced any
>> > of its new features on me and I can still program Pascal like I did when I
>> > started in the 90’s. Forcing me to use features is where my line is crossed
>> > but I struggle to understand why we’re withholding good ideas from users to
>> > this extent.
>> >
>>
>> You can make the function yourself.
>
>
> You can't, because the main point of the intrinsic was that the parameter
> that was in the branch not taken was not evaluated at all just like with the
> if-statement. Normal function calls will always evaluate the parameters.
>

I understand, but you can get close. That is why I mentioned type
safety. Ignoring those things seems kind of anti-Pascal way.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi

[Ben Grasset]

Ironically, type safety is a good argument for the further development of
various generics related things. Yet unfortunately I don't think anyone is
going to stop using the Contnrs unit in new code anytime soon...

[Sven Barth via fpc-pascal]

Ryan Joseph <***@thealchemistguild.com> schrieb am Mi., 18. Juli 2018,
21:37:

>
>
> > On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal <
> fpc-***@lists.freepascal.org> wrote:
> >
> > And to give you a slightly different example: around a year ago or so I
> implemented a IfThen() intrinsic that works like the if-statement, but as
> an expression (like C's trinary ?: operator including not evaluating the
> branch not taken). The majority of the users seemed to like it, but reasons
> against it surfaced and so I reverted it again.
> >
>
> That’s pretty disheartening honestly. So there was a useful feature users
> could be leveraging but it was turned down because it didn’t fit into some
> paradigm or something like that. Sorry to hear that.
>

Due to it essentially being an overload of IfThen in the Math unit there
was the possibility of confusion not to mention that it would be the only
function like construct that would not evaluate all parameters. When I'm
going to add it again I'm probably going the Oxygen route and use an
if-expression enabled with a modeswitch 🀷‍♀


Since I’ve been using FPC in 2003-2004 the language has never forced any of
> its new features on me and I can still program Pascal like I did when I
> started in the 90’s. Forcing me to use features is where my line is crossed
> but I struggle to understand why we’re withholding good ideas from users to
> this extent.
>

The problem with any language feature is this: even if I don't use it
someone else will and I'll sooner or later have to read such code. So in
that sense any language feature is forced upon everyone.

Regards,
Sven

>

[R0b0t1]

On Wed, Jul 18, 2018 at 3:57 PM, Sven Barth via fpc-pascal
<fpc-***@lists.freepascal.org> wrote:
> Ryan Joseph <***@thealchemistguild.com> schrieb am Mi., 18. Juli 2018,
> 21:37:
>>
>>
>>
>> > On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal
>> > <fpc-***@lists.freepascal.org> wrote:
>> >
>> > And to give you a slightly different example: around a year ago or so I
>> > implemented a IfThen() intrinsic that works like the if-statement, but as an
>> > expression (like C's trinary ?: operator including not evaluating the branch
>> > not taken). The majority of the users seemed to like it, but reasons against
>> > it surfaced and so I reverted it again.
>> >
>>
>> That’s pretty disheartening honestly. So there was a useful feature users
>> could be leveraging but it was turned down because it didn’t fit into some
>> paradigm or something like that. Sorry to hear that.
>
>
> Due to it essentially being an overload of IfThen in the Math unit there was
> the possibility of confusion not to mention that it would be the only
> function like construct that would not evaluate all parameters. When I'm
> going to add it again I'm probably going the Oxygen route and use an
> if-expression enabled with a modeswitch 🤷‍♀️
>
>
>> Since I’ve been using FPC in 2003-2004 the language has never forced any
>> of its new features on me and I can still program Pascal like I did when I
>> started in the 90’s. Forcing me to use features is where my line is crossed
>> but I struggle to understand why we’re withholding good ideas from users to
>> this extent.
>
>
> The problem with any language feature is this: even if I don't use it
> someone else will and I'll sooner or later have to read such code. So in
> that sense any language feature is forced upon everyone.
>

To go along with this, as it is all of the dialects of Pascal
supported by FPC make for a difficult to understand language
interface. Some of the "open" "standards" supported have very warty
featuresets already.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/lis

[Ben Grasset]

The "I might have to read code I don't like" argument people seem to keep
resorting to comes off as rather childish, frankly. It's entirely
subjective and specific to each person.

For example, does *anyone *actually think the strange "lowercase
everything" capitalization style the compiler uses is "readable" nowadays?
It seems rather unlikely that's what would have ended up being used if FPC
was started today.

On Wed, Jul 18, 2018 at 4:57 PM, Sven Barth via fpc-pascal <
fpc-***@lists.freepascal.org> wrote:

> Ryan Joseph <***@thealchemistguild.com> schrieb am Mi., 18. Juli 2018,
> 21:37:
>
>>
>>
>> > On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal <
>> fpc-***@lists.freepascal.org> wrote:
>> >
>> > And to give you a slightly different example: around a year ago or so I
>> implemented a IfThen() intrinsic that works like the if-statement, but as
>> an expression (like C's trinary ?: operator including not evaluating the
>> branch not taken). The majority of the users seemed to like it, but reasons
>> against it surfaced and so I reverted it again.
>> >
>>
>> That’s pretty disheartening honestly. So there was a useful feature users
>> could be leveraging but it was turned down because it didn’t fit into some
>> paradigm or something like that. Sorry to hear that.
>>
>
> Due to it essentially being an overload of IfThen in the Math unit there
> was the possibility of confusion not to mention that it would be the only
> function like construct that would not evaluate all parameters. When I'm
> going to add it again I'm probably going the Oxygen route and use an
> if-expression enabled with a modeswitch 🀷‍♀
>
>
> Since I’ve been using FPC in 2003-2004 the language has never forced any
>> of its new features on me and I can still program Pascal like I did when I
>> started in the 90’s. Forcing me to use features is where my line is crossed
>> but I struggle to understand why we’re withholding good ideas from users to
>> this extent.
>>
>
> The problem with any language feature is this: even if I don't use it
> someone else will and I'll sooner or later have to read such code. So in
> that sense any language feature is forced upon everyone.
>
> Regards,
> Sven
>
>>
> _______________________________________________
> fpc-pascal maillist - fpc-***@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

[Martin Schreiber]

On Wednesday 18 July 2018 23:30:19 Ben Grasset wrote:
>
> For example, does *anyone *actually think the strange "lowercase
> everything" capitalization style the compiler uses is "readable" nowadays?

Yes.

Martin
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.

[Ben Grasset]

I'm quite certain a lot of people would disagree with you on that. But
there you have the reason why the "having to read code you don't like
looking at" argument makes no sense. It's completely subjective.

On Thu, Jul 19, 2018 at 12:37 AM, Martin Schreiber <***@gmail.com>
wrote:

> On Wednesday 18 July 2018 23:30:19 Ben Grasset wrote:
> >
> > For example, does *anyone *actually think the strange "lowercase
> > everything" capitalization style the compiler uses is "readable"
> nowadays?
>
> Yes.
>
> Martin
> _______________________________________________
> fpc-pascal maillist - fpc-***@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

[Ben Grasset]

They observably *are* good though, now that they've been implemented,
especially in combination with management operators. These are features
that objectively make FPC better. I'm unsure what the original concern
could have even possibly been, other than some vague notion of "well,
records didn't have methods before, so they shouldn't now!".

Classes are unsuitable performance-wise for many use cases, and TP objects
lack important features such as variant parts. Advanced records are a great
lightweight in-between point.

On Tue, Jul 17, 2018 at 4:15 PM, Sven Barth via fpc-pascal <
fpc-***@lists.freepascal.org> wrote:

> Am 17.07.2018 um 20:00 schrieb Ryan Joseph:
>
>>
>> On Jul 17, 2018, at 11:27 AM, Jim Lee <***@gmail.com> 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-***@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

[Ryan Joseph]

> On Jul 18, 2018, at 7:14 AM, Ben Grasset <***@gmail.com> wrote:
>
> Classes are unsuitable performance-wise for many use cases, and TP objects lack important features such as variant parts. Advanced records are a great lightweight in-between point.

Yes indeed. Not being able to allocate classes on the stack is a scandal for Pascal. I don’t know why the devs decided classes must be on the heap and anything other than that would violate some supposed design principle (Delphi??).


Regards,
Ryan Joseph

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

[Sven Barth via fpc-pascal]

Ryan Joseph <***@thealchemistguild.com> schrieb am Mi., 18. Juli 2018,
19:00:

>
>
> > On Jul 18, 2018, at 7:14 AM, Ben Grasset <***@gmail.com> wrote:
> >
> > Classes are unsuitable performance-wise for many use cases, and TP
> objects lack important features such as variant parts. Advanced records are
> a great lightweight in-between point.
>
> Yes indeed. Not being able to allocate classes on the stack is a scandal
> for Pascal. I don’t know why the devs decided classes must be on the heap
> and anything other than that would violate some supposed design principle
> (Delphi??).
>

A point against stack based classes is that Object Pascal's object model is
highly geared towards polymorphism (with things like virtual class methods
and constructors that C++ does not support). You can't make use of this
however if the class is instantiated on the stack.

Regards,
Sven

>

[Ryan Joseph]

> On Jul 18, 2018, at 12:47 PM, Sven Barth via fpc-pascal <fpc-***@lists.freepascal.org> wrote:
>
> A point against stack based classes is that Object Pascal's object model is highly geared towards polymorphism (with things like virtual class methods and constructors that C++ does not support). You can't make use of this however if the class is instantiated on the stack.

Isn't that what Object does though? Something strange happened when FPC implemented classes because they didn’t unify the model between stack and heap. That was the obvious thing to do in my mind.

I remember back when I was using Objects and doing like C++ where I used new to allocate on the heap then dereference using ^. to access members. When classes came around I thought, this is nice, no more new and ^. everywhere and easier to use. Fast forward to today and I want the option to go stack based back but the models have diverged so much it’s not possible anymore.

Just now I wanted to use TFPGList and I wanted it on the stack because I didn’t want it to survive outside the function I was in. What do I do now?

Regards,
Ryan Joseph

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.f

[Sven Barth via fpc-pascal]

Ryan Joseph <***@thealchemistguild.com> schrieb am Mi., 18. Juli 2018,
21:41:

>
>
> > On Jul 18, 2018, at 12:47 PM, Sven Barth via fpc-pascal <
> fpc-***@lists.freepascal.org> wrote:
> >
> > A point against stack based classes is that Object Pascal's object model
> is highly geared towards polymorphism (with things like virtual class
> methods and constructors that C++ does not support). You can't make use of
> this however if the class is instantiated on the stack.
>
> Isn't that what Object does though? Something strange happened when FPC
> implemented classes because they didn’t unify the model between stack and
> heap. That was the obvious thing to do in my mind.
>

You have to keep in mind the history here. The "object" type is from Turbo
Pascal times and back then it already showed its weaknesses. Then along
came Delphi and Borland decided to introduce a brand new object model based
on the "class" type which tackled the weak points of the "object" type and
introduced some more polymorphism for the type.
You can't utilize polymorphism with "object" instances in the stack either.


> I remember back when I was using Objects and doing like C++ where I used
> new to allocate on the heap then dereference using ^. to access members.
> When classes came around I thought, this is nice, no more new and ^.
> everywhere and easier to use. Fast forward to today and I want the option
> to go stack based back but the models have diverged so much it’s not
> possible anymore.
>
> Just now I wanted to use TFPGList and I wanted it on the stack because I
> didn’t want it to survive outside the function I was in. What do I do now?
>

I really wonder why you keep thinking that you need them on the stack. I'm
developing in Object Pascal (and this the "class" based model) for around
16 years or so and I never felt the need to put a class on the stack. I'm
saying that while I also work with C++ at work for nearly 5 years and *do*
use stack based structs and classes there.

Regards,
Sven

>

[Ryan Joseph]

> On Jul 18, 2018, at 3:05 PM, Sven Barth via fpc-pascal <fpc-***@lists.freepascal.org> wrote:
>
> You have to keep in mind the history here. The "object" type is from Turbo Pascal times and back then it already showed its weaknesses. Then along came Delphi and Borland decided to introduce a brand new object model based on the "class" type which tackled the weak points of the "object" type and introduced some more polymorphism for the type.
> You can't utilize polymorphism with "object" instances in the stack either.

I didn’t know object had polymorphism limitations. What are they exactly?

> I really wonder why you keep thinking that you need them on the stack. I'm developing in Object Pascal (and this the "class" based model) for around 16 years or so and I never felt the need to put a class on the stack. I'm saying that while I also work with C++ at work for nearly 5 years and *do* use stack based structs and classes there.

1) For general efficiency of not allocating a block of memory on the heap when I know for absolute 100% certainty I don’t need it beyond the current stack frame. For high performance situations it really does matter since you start dealing with heap fragmentation and extra overhead with the memory manager. I was doing a game engine recently and doing the create/free thing when I knew I didn’t have to was painful.

2) Often when declaring a variable I know with absolute 100% certainty that it will not survive the stack frame and I’ll be calling Free at the end of the function. I’d like to just stop thinking about memory management at that point and be ensured the class will be freed at the end of the function. C++ calls the destructor for you but FPC doesn’t do this for some reason. Why?

Regards,
Ryan Joseph

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/list

[Reimar Grabowski]

On Wed, 18 Jul 2018 15:39:58 -0600
Ryan Joseph <***@thealchemistguild.com> wrote:

> 1) For high performance situations it really does matter... <snip> I was doing a game engine recently and doing the create/free thing when I knew I didn’t have to was painful.

For high performance in a game engine you should not allocate/deallocate memory in the game loop at all (can be done, have done it*, so no arguing there). Increases the performance and frees you of doing "the create/free thing", that's killing two birds with one stone. Outside the game loop you do not need such a 'high performance' anymore.

R.

*The game uses procedural/random level generation and depending on skill there can be over 300 levels in a single run, with all allocation/deallocation happening before/after a run.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.

[Ben Grasset]

> For high performance in a game engine you should not allocate/deallocate
memory in the game loop at all (can be done, have done it*, so no arguing
there).

This is a massive oversimplification. Many *modern* game engines do not
even have the kind of loop you're thinking of.

> Outside the game loop you do not need such a 'high performance' anymore.

Says who?

On Wed, Jul 18, 2018 at 9:08 PM, Reimar Grabowski <***@web.de> wrote:

> On Wed, 18 Jul 2018 15:39:58 -0600
> Ryan Joseph <***@thealchemistguild.com> wrote:
>
> > 1) For high performance situations it really does matter... <snip> I was
> doing a game engine recently and doing the create/free thing when I knew I
> didn’t have to was painful.
>
> For high performance in a game engine you should not allocate/deallocate
> memory in the game loop at all (can be done, have done it*, so no arguing
> there). Increases the performance and frees you of doing "the create/free
> thing", that's killing two birds with one stone. Outside the game loop you
> do not need such a 'high performance' anymore.
>
> R.
>
> *The game uses procedural/random level generation and depending on skill
> there can be over 300 levels in a single run, with all
> allocation/deallocation happening before/after a run.
> _______________________________________________
> fpc-pascal maillist - fpc-***@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

[Reimar Grabowski]

On Wed, 18 Jul 2018 21:26:05 -0400
Ben Grasset <***@gmail.com> wrote:

> This is a massive oversimplification. Many *modern* game engines do not
> even have the kind of loop you're thinking of.
Please tell me where I can read up about those engines without cyclic executive?
Are those engines interrupt driven or how are they working?
Where is the gain in not having a loop?
Keeping your timing consistent with just semaphores sounds like a nightmare to me and not a win.
In the end the loop is in the OS (listening for events/interrupts) no matter what you do (except using a real time OS, but I don't know any console running on one (they run BSD) and PC gaming is Windows).
I am little out of the loop (no pun intended) regarding game engines so which engines are *modern*?
Unreal 5 does still have a loop and current Unity, too, so they seem to be old fashioned (contrary to me thinking they are modern).

>> Outside the game loop you do not need such a 'high performance' anymore.
>Says who?
Mr. Common-Sense says that you can waste a few nano/milliseconds if you are outside a run and only updating (slow) user input and interface (menus).
But he's not always right and eager to hear about situations where this time cannot be spent.

R.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.

[Ben Grasset]

Well, the array TFPGList uses for storage would still be allocated on the
heap in any case no matter what...

On Wed, Jul 18, 2018 at 3:10 PM, Ryan Joseph <***@thealchemistguild.com>
wrote:

>
>
> > On Jul 18, 2018, at 12:47 PM, Sven Barth via fpc-pascal <
> fpc-***@lists.freepascal.org> wrote:
> >
> > A point against stack based classes is that Object Pascal's object model
> is highly geared towards polymorphism (with things like virtual class
> methods and constructors that C++ does not support). You can't make use of
> this however if the class is instantiated on the stack.
>
> Isn't that what Object does though? Something strange happened when FPC
> implemented classes because they didn’t unify the model between stack and
> heap. That was the obvious thing to do in my mind.
>
> I remember back when I was using Objects and doing like C++ where I used
> new to allocate on the heap then dereference using ^. to access members.
> When classes came around I thought, this is nice, no more new and ^.
> everywhere and easier to use. Fast forward to today and I want the option
> to go stack based back but the models have diverged so much it’s not
> possible anymore.
>
> Just now I wanted to use TFPGList and I wanted it on the stack because I
> didn’t want it to survive outside the function I was in. What do I do now?
>
> Regards,
> Ryan Joseph
>
> _______________________________________________
> fpc-pascal maillist - fpc-***@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

[Ryan Joseph]

> On Jul 18, 2018, at 4:01 PM, Ben Grasset <***@gmail.com> wrote:
>
> Well, the array TFPGList uses for storage would still be allocated on the heap in any case no matter what…

That’s true but the other part remains true.

Here’s from the FPC compiler itself. sc is declared at the top and ~400 lines later it’s freed. If they knew they were going to free at the end of the function anyways why did they have to go all the way to bottom to do it? if you want to make sure it’s freed you need to scroll through the entire 400 lines to confirm this.

Personally for my taste I would like to just add a little keyword to the end of the variable so I don’t have to worry about it later.

var
sc : TFPObjectList;
begin
old_block_type:=block_type;
block_type:=bt_var;
recst:=tabstractrecordsymtable(symtablestack.top);
{$if defined(powerpc) or defined(powerpc64)}
is_first_type:=true;
{$endif powerpc or powerpc64}
{ Force an expected ID error message }
if not (token in [_ID,_CASE,_END]) then
consume(_ID);
{ read vars }
sc:=TFPObjectList.create(false);

**************** 400 lines later…. ****************

{ free the list }
sc.free;
{$ifdef powerpc}
is_first_type := false;
{$endif powerpc}
block_type:=old_block_type;
end;

Regards,
Ryan Joseph

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal

[Reimar Grabowski]

On Wed, 18 Jul 2018 16:12:41 -0600
Ryan Joseph <***@thealchemistguild.com> wrote:

> Personally for my taste I would like to just add a little keyword to the end of the variable so I don’t have to worry about it later.

1) little, innocent deallocation feature A
2) other user comes along: "We already have A, can it be improved a little to work in situation X, too?"
3) n other users come along
4) "Pascal garbage collection - You have earned a trophy!" ;)

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

[Ben Grasset]

Yawn, more F.U.D.

On Wed, Jul 18, 2018 at 9:20 PM, Reimar Grabowski <***@web.de> wrote:

> On Wed, 18 Jul 2018 16:12:41 -0600
> Ryan Joseph <***@thealchemistguild.com> wrote:
>
> > Personally for my taste I would like to just add a little keyword to the
> end of the variable so I don’t have to worry about it later.
>
> 1) little, innocent deallocation feature A
> 2) other user comes along: "We already have A, can it be improved a little
> to work in situation X, too?"
> 3) n other users come along
> 4) "Pascal garbage collection - You have earned a trophy!" ;)
>
> R.
> _______________________________________________
> fpc-pascal maillist - fpc-***@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

[Tomas Hajny]

Hello everybody,

The discussion in this thread seems to be endless and arguments are
repeating over and over. Moreover, some of the words and statements having
appeared in certain posts are better avoided in polite communication.
Everybody, please, think twice whether your post adds value (repetition of
arguments and previously declined feature requests does not, attacks even
less).

Thank you

Tomas
(one of FPC mailing list moderators)


_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepasca

[Bo Berglund]

On Thu, 19 Jul 2018 03:42:26 +0200, "Tomas Hajny"
<***@hajny.biz> wrote:

>Hello everybody,
>
>The discussion in this thread seems to be endless and arguments are
>repeating over and over. Moreover, some of the words and statements having
>appeared in certain posts are better avoided in polite communication.
>Everybody, please, think twice whether your post adds value (repetition of
>arguments and previously declined feature requests does not, attacks even
>less).
>
>Thank you
>
>Tomas
>(one of FPC mailing list moderators)

+1

And please move this thread to the free-pascal.social group...


--
Bo Berglund
Developer in Sweden

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

[Marco van de Voort]

In our previous episode, Ryan Joseph said:
>
> That?s pretty disheartening honestly. So there was a useful feature users
> could be leveraging but it was turned down because it didn?t fit into some
> paradigm or something like that. Sorry to hear that.

No, because blind copying from one language to another is not always
feasible.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.fre

[Ben Grasset]

If a feature works as intended and is useful (which is all that matters),
how is it "blind copying"?

On Thu, Jul 19, 2018 at 7:25 AM, Marco van de Voort <***@stack.nl> wrote:

>
> In our previous episode, Ryan Joseph said:
> >
> > That?s pretty disheartening honestly. So there was a useful feature users
> > could be leveraging but it was turned down because it didn?t fit into
> some
> > paradigm or something like that. Sorry to hear that.
>
> No, because blind copying from one language to another is not always
> feasible.
> _______________________________________________
> fpc-pascal maillist - fpc-***@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

[Sven Barth via fpc-pascal]

Am 20.07.2018 um 00:53 schrieb Ben Grasset:
> If a feature works as intended and is useful (which is all that
> matters), how is it "blind copying"?
Because a feature might change the language in a way that's not in the
spirit of the language. Look at how Delphi implemented attributes:
they're declared in front of the types, fields, parameters, whatever,
simply copied from how C# implemented them while in the spirit of Pascal
they should have been *after* the declarations.

Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.o

[R0b0t1]

On Fri, Jul 20, 2018 at 12:20 AM, Sven Barth via fpc-pascal
<fpc-***@lists.freepascal.org> wrote:
> Am 20.07.2018 um 00:53 schrieb Ben Grasset:
>>
>> If a feature works as intended and is useful (which is all that matters),
>> how is it "blind copying"?
>
> Because a feature might change the language in a way that's not in the
> spirit of the language. Look at how Delphi implemented attributes: they're
> declared in front of the types, fields, parameters, whatever, simply copied
> from how C# implemented them while in the spirit of Pascal they should have
> been *after* the declarations.
>

This is what bothers me about some of the Delphi extensions that are
requested, but also some things that are already in FPC. And like
other people have said: now it's too late. It's there forever, or a
length of time that is just as good when talking about software.

It's not to say all of these things are bad - it's just I wish more
thought would have gone into them. Perhaps that would mean changing
the feature so much that it doesn't resemble what was originally
proposed.

Cheers,
R0b0t1
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/list

[Ben Grasset]

Isn't Delphi compatibility a major ongoing goal of both FPC and Lazarus,
though?

On Fri, Jul 20, 2018 at 10:01 AM, R0b0t1 <***@gmail.com> wrote:

> On Fri, Jul 20, 2018 at 12:20 AM, Sven Barth via fpc-pascal
> <fpc-***@lists.freepascal.org> wrote:
> > Am 20.07.2018 um 00:53 schrieb Ben Grasset:
> >>
> >> If a feature works as intended and is useful (which is all that
> matters),
> >> how is it "blind copying"?
> >
> > Because a feature might change the language in a way that's not in the
> > spirit of the language. Look at how Delphi implemented attributes:
> they're
> > declared in front of the types, fields, parameters, whatever, simply
> copied
> > from how C# implemented them while in the spirit of Pascal they should
> have
> > been *after* the declarations.
> >
>
> This is what bothers me about some of the Delphi extensions that are
> requested, but also some things that are already in FPC. And like
> other people have said: now it's too late. It's there forever, or a
> length of time that is just as good when talking about software.
>
> It's not to say all of these things are bad - it's just I wish more
> thought would have gone into them. Perhaps that would mean changing
> the feature so much that it doesn't resemble what was originally
> proposed.
>
> Cheers,
> R0b0t1
> _______________________________________________
> fpc-pascal maillist - fpc-***@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

[Michael Van Canneyt]

On Fri, 20 Jul 2018, Sven Barth via fpc-pascal wrote:

> Am 20.07.2018 um 00:53 schrieb Ben Grasset:
>> If a feature works as intended and is useful (which is all that
>> matters), how is it "blind copying"?
> Because a feature might change the language in a way that's not in the
> spirit of the language. Look at how Delphi implemented attributes:
> they're declared in front of the types, fields, parameters, whatever,
> simply copied from how C# implemented them while in the spirit of Pascal
> they should have been *after* the declarations.

There is more to a language than 'works as intended and is useful'.

If this were "all that matters", you must consequently switch to the language
with the most features (whatever it is these days). Many do so.

But there can be other criteria as well. For example readability.
I find the C family of languages with their abundance of brackets utterly unreadable.
Conciseness is also valued by many.
Scala for example is very concise, but because of this, utterly unreadable.
I often need to re-read a statement 3 times to understand what is happening.

This is not to say that Pascal should stay immutable, or that readability is
the only criterion.

There is definitely room for improvement in Pascal.
And improvements will be made, but adhering to the spirit of Pascal.
(intentionally left undefined)

Michael.

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

[Ben Grasset]

On Fri, Jul 20, 2018 at 1:20 AM, Sven Barth via fpc-pascal <
fpc-***@lists.freepascal.org> wrote:
>
> Because a feature might change the language in a way that's not in the
> spirit of the language. Look at how Delphi implemented attributes: they're
> declared in front of the types, fields, parameters, whatever, simply copied
> from how C# implemented them while in the spirit of Pascal they should have
> been *after* the declarations.
>
> Regards,
> Sven
>
> _______________________________________________
> fpc-pascal maillist - fpc-***@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>


C# itself is heavily inspired by Delphi though, as it's another Anders
Hejlsberg project. I fail to see what the "spirit of the language" has to
do with anything as far as attributes, either.

Shouldn't the attribute tags just be put wherever it's easiest for the
compiler to deal with them?

I think the vast majority of people care far more about how *useful
Pascal actually
is in real life* than they do
about whether or not it fulfills some not-well-defined notion of "spirit".

Also, as far as I can tell, most of the people who use FPC would consider
the Delphi way to be the correct or normal way of doing things in the first
place.

[James Lee]

On 7/21/2018 1:43 PM, Ben Grasset wrote:
>
> Shouldn't the attribute tags just be put wherever it's easiest for the
> compiler to deal with them?
>

That would be bending the language to fit the implementation, when it
should be the other way around.

> I think the vast majority of people care far more about
> how/usefulPascal actually is in real life/than they do
> about whether or not it fulfills some not-well-defined notion of
> "spirit".
>

Not me.  No computer language is a one-size-fits-all solution, nor
should it be - though we have several  languages to choose from that are
trying to be.

> Also, as far as I can tell, most of the people who use FPC would
> consider the Delphi way to be the correct or normal way of doing
> things in the first place.
>

Again, not me.  Several Delphi features were rushed to meet a release
deadline and were not well thought out.

-Jim

[Marco van de Voort]

In our previous episode, Ben Grasset said:
> If a feature works as intended and is useful (which is all that matters),

The first is not sure, the second is extremely subjective.

The point is that border conditions can vary between source and destination
language. How features parse, how they interact with other features etc etc,
whether it is supportable long term.

> how is it "blind copying"?

Because such statements (as your first line above) are blind to those
considerations.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/