Syntax changes suggestions

classic Classic list List threaded Threaded
113 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Michael Fuchs-5
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Michael Van Canneyt
In reply to this post by Santiago A.


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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Free Pascal - General mailing list
In reply to this post by Santiago A.
Santiago A. <[hidden email]> 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 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Santiago A.
El 16/07/2018 a las 15:02, Sven Barth via fpc-pascal escribió:
Santiago A. <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


-- 
Saludos

Santiago A.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Santiago A.
In reply to this post by Michael Van Canneyt
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Martin Friebe
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Anthony Walter-3
To the OP:

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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

R0b0t1
In reply to this post by Santiago A.
On Mon, Jul 16, 2018 at 6:40 AM, Santiago A. <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Free Pascal - General mailing list
In reply to this post by Santiago A.
Santiago A. <[hidden email]> schrieb am Mo., 16. Juli 2018, 16:27:
El 16/07/2018 a las 15:02, Sven Barth via fpc-pascal escribió:
Santiago A. <[hidden email]> 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 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Free Pascal - General mailing list
In reply to this post by R0b0t1
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

R0b0t1
On Mon, Jul 16, 2018 at 3:28 PM, Sven Barth via fpc-pascal
<[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Ralf Quint
In reply to this post by Anthony Walter-3
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


Virus-free. www.avast.com

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Ryan Joseph
In reply to this post by Free Pascal - General mailing list


> On Jul 16, 2018, at 7:02 AM, Sven Barth via fpc-pascal <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Ryan Joseph
In reply to this post by Santiago A.


> On Jul 16, 2018, at 8:27 AM, Santiago A. <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Ryan Joseph
In reply to this post by R0b0t1


> On Jul 16, 2018, at 11:55 AM, R0b0t1 <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Ryan Joseph
In reply to this post by Marco van de Voort


> On Jul 16, 2018, at 1:27 PM, Marco van de Voort <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Free Pascal - General mailing list
In reply to this post by R0b0t1
Am 16.07.2018 um 23:14 schrieb R0b0t1:

> On Mon, Jul 16, 2018 at 3:28 PM, Sven Barth via fpc-pascal
> <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Free Pascal - General mailing list
In reply to this post by Ryan Joseph
Am 17.07.2018 um 04:48 schrieb Ryan Joseph:
>
>> On Jul 16, 2018, at 7:02 AM, Sven Barth via fpc-pascal <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
1234 ... 6