Re: [fpc-pascal] Loss of precision when using math.Max()

[Martok]

Am 14.07.2018 um 13:42 schrieb Florian Klämpfl:
>> Still, the Delphi(32) compiler always works with Extended precision at 
>> compile
>> time. See
>> :
>> "If constantExpression is a real, its type is Extended" - that type then 
>> propagates.
> 
> Yes, this is for sure x87 inheritance. On x87 it is in practice always the 
> case that operations are carried out with 
> extended precision.
Probably. All their current compilers are still pure win32 applications... I
have a suspicion that the fact that they put many x87 specific things in the
reference might be part of the reason.

This is impossible to replicate on FPC (without using the same softfloat on all
platforms), so the current situation is the only consistent solution.
It is missing documentation however: AFAICS, there is currently no reference for
real literal types, and a user inferring from Delphi will have the wrong
expectation.


Regards,

Martok

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

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

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

Re: [fpc-pascal] Syntax changes suggestions

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

Re: [fpc-pascal] Syntax changes suggestions

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

Re: [fpc-pascal] Syntax changes suggestions

[Sven Barth via fpc-pascal]

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

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

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

Re: [fpc-pascal] Syntax changes suggestions

[Santiago A.]

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



--
Saludos

Santiago A.

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

Re: [fpc-pascal] Syntax changes suggestions

[Santiago A.]

El 16/07/2018 a las 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='';
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-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

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

Re: [fpc-pascal] Syntax changes suggestions

[Anthony Walter]

To the OP:

For the sake of brevity, my vote is simply "no" to all your suggestions.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[R0b0t1]

On Mon, Jul 16, 2018 at 6:40 AM, 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

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

Re: [fpc-pascal] Syntax changes suggestions

[Sven Barth via fpc-pascal]

Santiago A.  schrieb am Mo., 16. Juli 2018, 16:27:

> El 16/07/2018 a las 15:02, Sven Barth via fpc-pascal escribió:
>
> Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:
>
>> I have some suggestions of change to freepascal syntax, just to debate
>>
>> (All are backward compatible)
>>
>> - Declaring variables inside blocks, and loop variables
>>
> -> reduces readability -> no interest
>
> 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Marco van de Voort]

In our previous episode, Sven Barth via fpc-pascal said:
> > 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-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Sven Barth via fpc-pascal]

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

Re: [fpc-pascal] Syntax changes suggestions

[R0b0t1]

On Mon, Jul 16, 2018 at 3:28 PM, Sven Barth via fpc-pascal
 wrote:
> Am 16.07.2018 um 19:55 schrieb R0b0t1:
>>
>>
>>> - Try except finally blocks
>>
>> I can support this one, I am surprised it is not already supported.
>> Wasn't this mentioned in another recent thread as existing? Does it
>> exist in at least Delphi mode?
>
>
> This is not supported and the last time it was discussed here on the mailing
> lists it was shot down (though I can't find the thread currently...).
> Also why should it exist in Delphi mode when Delphi does not support it?
> (Yes, there are some features that work in Delphi mode that Delphi doesn't
> support, but in generic the purpose of mode Delphi is to support Delphi
> code)

From my searching it is in (newer?) Delphi. I can't admit to being a
huge fan of "finally" (I don't typically use it myself) but I am
interested in why it is not supported.

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

Re: [fpc-pascal] Syntax changes 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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ryan Joseph]

> On Jul 16, 2018, at 8:27 AM, Santiago A.  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-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ryan Joseph]

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

Re: [fpc-pascal] Syntax changes suggestions

[Ryan Joseph]

> On Jul 16, 2018, at 11:55 AM, R0b0t1  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-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ryan Joseph]

> On Jul 16, 2018, at 1:27 PM, Marco van de Voort  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-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Sven Barth via fpc-pascal]

Am 16.07.2018 um 23:14 schrieb R0b0t1:

On Mon, Jul 16, 2018 at 3:28 PM, Sven Barth via fpc-pascal
 wrote:

Am 16.07.2018 um 19:55 schrieb R0b0t1:



- Try except finally blocks

I can support this one, I am surprised it is not already supported.
Wasn't this mentioned in another recent thread as existing? Does it
exist in at least Delphi mode?


This is not supported and the last time it was discussed here on the mailing
lists it was shot down (though I can't find the thread currently...).
Also why should it exist in Delphi mode when Delphi does not support it?
(Yes, there are some features that work in Delphi mode that Delphi doesn't
support, but in generic the purpose of mode Delphi is to support Delphi
code)

 From my searching it is in (newer?) Delphi. I can't admit to being a
huge fan of "finally" (I don't typically use it myself) but I am
interested in why it is not supported.


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

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


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

Re: [fpc-pascal] Syntax changes suggestions

[Sven Barth via fpc-pascal]

Am 17.07.2018 um 04:48 schrieb Ryan Joseph:



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