Re: [fpc-devel] "Blank slate" next version of FPC

[Ondrej Pokorny]

Am 20.02.19 um 21:33 schrieb Florian Klämpfl


> Am 20.02.19 um 08:36 schrieb Paul van Helden:
> As a big
>/fan of the Pascal language, I'd rather break compatibility and see the /> 
>/language evolve than the stoic attitude of the core devs as seen on this /> >/list. 
/
People could change this attitude by contributing to FPC. But very few 
do constantly with high quality patches.


Not at all. My experience is that contributing to FPC compiler development is 
just a waste of time.
1.) First you have to convince core compiler developers that your idea is good. 
This usually starts a long discussion with different opinions like this one. 
(That's why I don't take part in it.)
2.) If you then hear "patches welcome", take your time and send your patch, you often 
don't get any kind of feedback and your issue report stays open forever. You actually don't know if 
your patch is just poor quality or if the people who said "patches welcome" said it just 
to end the discussion and counted on the fact that you would never send a patch.

You wrote the reason yourself:

The current FPC devs are simply 
overloaded with the areas they have to maintain so it is pretty clear 
that excitement about new features is very low.


Yes, this is the true excuse that I also accept.

No rant. Just saying how the reality is. As an external contributor, you cannot 
change anything - and especially not the attitude of core compiler developers. 
It's just better to be happy with what FPC offers, don't lose your time and the 
time of FPC core developers with useless discussions about new features, don't 
lose your time with developing and sending patches, accept features and 
behavior you don't like and live with them. If you really want to use your 
feature set, maintain your own personal FPC fork.


Please don't misunderstand me - I want to stress that in the end I do like this attitude 
of FPC core developers to be very critical about external patches and new features. It 
could end up in a horrible mess if every idea and every patch is applied. I do like the 
attitude "if I am not 100% sure about a patch/feature, I don't apply it". I 
just have to dispute that we (external contributors) can change something.


(Just a note: I regret that Sven withdrew his IfThen compiler intrinsic, though 
:) )

Ondrej

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

Re: [fpc-devel] "Blank slate" next version of FPC

[James via fpc-devel]

Well, I asked for discussion, and it was given. Thank you all for your input.

To be clear, although I *literally* wrote the words "non backwards compatible", 
I did not mean it. I should have said that there should be a new compiler mode 
to access new features. In Rust, there is the concept of "safe" vs "unsafe" 
code. "Safe" code is guaranteed to be memory and type safe. For a new Pascal 
mode, code marked "Unsafe" would merely be code written to compile under any of 
the currently supported modes.

Someone pointed out that a main goal of Pascal was to keep one from shooting 
oneself in the foot. It is this spirit that I think should be extended (if 
possible) to adopt at least the memory safe aspect of Rust. There are other 
programming constructs unrelated to safety which I think merit examination, 
also.

I might have time later in the year to work on fleshing out the syntax of a new 
FPC mode. Perhaps someone who is intimately familiar with the compiler 
internals can mentor me and guide me to understand where I am wrong, and what 
lines of thought would be productive. I would be willing to pay for the help.

Regardless, thank you for the discussion.
-James___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Michael Schnell]

>. For us inline variables is one of the most horrid if not *the* most horrid 
>thing Embarcadero could have done to Object Pascal.

Can you tell us why ?

(In C I often declare variables just before using them and I indeed would even 
like to do “for (int i = 0; i<10; i++) {a[i] = a[i+1];}  ☺

-Michael


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

Re: [fpc-devel] "Blank slate" next version of FPC

[Michael Schnell]

> If Oxygene was open source and (CPU) native,

Oxygen *is* CPU native (optionally). But not open source, and of course there 
are a lot more drawbacks regarding fpc/Lazarus.

-Michael



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

Re: [fpc-devel] "Blank slate" next version of FPC

[J. Gareth Moreton]

 On the contrary... I'm all for new features if they gel well with the
language, although I try to research and theorise how they can benefit the
compiler and the code it generates.  My current patches haven't been as
well-received as I had hoped, possibly due to lack of documentation and
provable stability etc.  (The biggest one overhauls the x86 Peephole
Optimizer by merging 6 passes into 1 for a speed boost of up to 15% on -O3,
but some of the individual optimisation routines are more complex as a
result, mostly so -O1 and -O2 don't perform worse).
 I'm wondering now, in the name of project management, if such feature
proposals and patches should come with a comprehensive design spec, if not
to justify the changes then to at least explain how everything works.

 Gareth aka. Kit

 On Wed 20/02/19 20:33 , Florian Klämpfl flor...@freepascal.org sent:
 Am 20.02.19 um 08:36 schrieb Paul van Helden: 
 > As a big 
 > fan of the Pascal language, I'd rather break compatibility and see the 
 > language evolve than the stoic attitude of the core devs as seen on this

 > list. 

 People could change this attitude by contributing to FPC. But very few 
 do constantly with high quality patches. The current FPC devs are simply 
 overloaded with the areas they have to maintain so it is pretty clear 
 that excitement about new features is very low. 
 ___ 
 fpc-devel maillist - fpc-devel@lists.freepascal.org [1] 
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 

 

Links:
--
[1] mailto:fpc-devel@lists.freepascal.org
[2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Sven Barth via fpc-devel]

Am Mi., 20. Feb. 2019, 20:45 hat gabor  geschrieben:

> W dniu 2019-02-16 o 23:37, Benito van der Zander pisze:
> > So are inline variables coming soon?
> >
> http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html
>
> Who cares ininline variables since we do not have dynamic packages yet
>

Those are at least on a good way. 3.2 contains many of the adjustments and
extensions needed to allow them. My hope is to enable them some time in
3.3.1.

Regards,
Sven

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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi,

20.02.2019 23:33, Florian Klämpfl:

Am 20.02.19 um 08:36 schrieb Paul van Helden:
 > As a big

fan of the Pascal language, I'd rather break compatibility and see the
language evolve than the stoic attitude of the core devs as seen on
this list.


People could change this attitude by contributing to FPC. But very few
do constantly with high quality patches. The current FPC devs are simply
overloaded with the areas they have to maintain so it is pretty clear
that excitement about new features is very low.


Now this is fair and reasonable, indeed.

I didn't actually intended to trigger such a blowup, just was curious 
about some possible specific technical reasons for avoiding inline 
declarations altogether.



Thank you,

Regards,
Nikolai


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


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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

20.02.2019 21:28, Giuliano Colla:
[...]

Moreover, using a modern tool such as Lazarus, you never need to scroll
1000 lines to find a declaration: you just press alt+Up to go to the
declaration of the symbol over the cursor, and Ctrl+H to go back to the
line of code.


It's a bit like car manufacturer saying, "we've arranged a steering 
wheel in the trunk but you need not worry, there are third-party 
extenders allowing to also access it from a driver's seat."



Keeping all declarations separated from code is just good programming
practice. Mixing declaration and code is bad programming practice, IMO,
and I appreciate Pascal for not supporting it.


Are you really sure? What about:

procedure Test;
var
  a: integer;
  function b(c: integer): integer;
  begin
b := 10 + 5 * c;
  end;
var
  d: integer;
begin
  d := b(1); a := 2;
end;

What is it if not mixing declaration and code?


Thank you,

Regards,
Nikolai



Giuliano



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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi,

20.02.2019 23:56, wkitt...@windstream.net:
[...]

How this example is different from e.g. using normally declared "I, J:
Integer" and employing "J" as a loop variable? Wouldn't it do the same
error anyway?



i think he's pointing out the two instances of

var I

in the code... one at the top and one in the loop... at best that would
be a redeclaration defect in the code to me...


I'd suppose inline redeclaration of an already existing local variable 
or parameter name should be prohibited. If Embarcadero allows that then 
they must be quite crazy...



Thank you,

Regards,
Nikolai






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

Re: [fpc-devel] "Blank slate" next version of FPC

[wkitty42]

On 2/20/19 1:28 PM, Giuliano Colla wrote:

Keeping all declarations separated from code is just good programming
practice. Mixing declaration and code is bad programming practice, IMO, and I
appreciate Pascal for not supporting it.


this falls in the same line as keeping business logic separate from data :)


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

Re: [fpc-devel] "Blank slate" next version of FPC

[wkitty42]

On 2/20/19 2:08 PM, Nikolai Zhubr wrote:

20.02.2019 18:24, Dimitrios Chr. Ioannidis via fpc-devel:
[...]

 I'd like to see an example how this is less safe.


Well one of the answer in the Cantu blog has this ( which I changed to
lets say a "real world" relative big function ) :


How this example is different from e.g. using normally declared "I, J: Integer" 
and employing "J" as a loop variable? Wouldn't it do the same error anyway?



i think he's pointing out the two instances of

  var I

in the code... one at the top and one in the loop... at best that would be a 
redeclaration defect in the code to me...



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

Re: [fpc-devel] "Blank slate" next version of FPC

[Florian Klämpfl]

Am 20.02.19 um 08:36 schrieb Paul van Helden:
> As a big
fan of the Pascal language, I'd rather break compatibility and see the 
language evolve than the stoic attitude of the core devs as seen on this 
list. 


People could change this attitude by contributing to FPC. But very few 
do constantly with high quality patches. The current FPC devs are simply 
overloaded with the areas they have to maintain so it is pretty clear 
that excitement about new features is very low.

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

Re: [fpc-devel] "Blank slate" next version of FPC

[Marcos Douglas B. Santos]

On Wed, Feb 20, 2019 at 4:28 PM Nikolai Zhubr  wrote:
>
> [...]
>
> On the other hand, I've been biten plenty by the already existing name
> clashes like:
>
>with Button1 do
>begin
>  Left := ClientWidth div 2;
>  .
>
> and here nothing can probably be done to help at compiler part, because
> the statement is perfectly valid despite so obviously erroneous. I've
> seen some people even prepending "self." to almost any identifier in a
> desperate attempt to eliminate ambiguities. (And yes, it looked
> disgusting enough)

So, instead of add more features, I would recommend we fix some
ambiguous structure like this.

regards,
Marcos Douglas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Marcos Douglas B. Santos]

On Wed, Feb 20, 2019 at 1:50 PM Kostas Michalopoulos
 wrote:
>
> > and Niklaus Wirth might not throw a curse in us.
>
> Considering we're talking about a dialect with three different
> incompatible yet mostly overlapping object systems, i think the curse
> has already been cast long long ago :-P.

Touché. Then, at least let try to save our soul  :)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[gabor]

W dniu 2019-02-16 o 23:37, Benito van der Zander pisze:
So are inline variables coming soon? 
http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html


Who cares ininline variables since we do not have dynamic packages yet?

Regards, Michał.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi,
20.02.2019 21:28, Giuliano Colla:
[...]

I have just met such a situation: I ported from C++ to Pascal an
algorithm for the computation of the kinematics of a Delta Robot, and I
was badly bitten.
In that case you are just dealing with X,Y,Z coordinates, and
Theta0,Theta1,and Theta2 angles, and you find, in the body of a
procedure, some X,Y,Z or Theta which have global scope, and some which
are just local to some smaller (but not too small) block and which are
redeclared inline. Rather hard to tell them apart.


Excellent! Such redeclarations should obviously be borbidden. Otherwise 
it would loose almost the whole point. Java certainly rejects them.
And, it is easy to identify and reject such name clashes in this case, 
because the offending statement (declaration) can clearly be located.


On the other hand, I've been biten plenty by the already existing name 
clashes like:


  with Button1 do
  begin
Left := ClientWidth div 2;
.

and here nothing can probably be done to help at compiler part, because 
the statement is perfectly valid despite so obviously erroneous. I've 
seen some people even prepending "self." to almost any identifier in a 
desperate attempt to eliminate ambiguities. (And yes, it looked 
disgusting enough)



Thank you,

Regards,
Nikolai


Redeclaring inline an index I, which you'll be then using a lot of
times, is the best way to shoot you in the feet. Pascal encourages you
to use I,J,K at first, then ii,jj,kk etc.

Moreover, using a modern tool such as Lazarus, you never need to scroll
1000 lines to find a declaration: you just press alt+Up to go to the
declaration of the symbol over the cursor, and Ctrl+H to go back to the
line of code.

Keeping all declarations separated from code is just good programming
practice. Mixing declaration and code is bad programming practice, IMO,
and I appreciate Pascal for not supporting it.

Giuliano



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

Re: [fpc-devel] "Blank slate" next version of FPC

[Martin Frb]

On 20/02/2019 19:56, Nikolai Zhubr wrote:

2) Nested loops exist. If in the middle of such a 1000 line for-loop, I
want to declare another loop, then I need to find a free identifier for
that variable.  Today, I can do that by looking at the declaration on 
top of the

procedure (and afaik depending on context, the class fields).
With inline declaration, I have to find each of the 10 surrounding
for-loops, scattered over a 1000 lines (And that is ignoring any
variables declared inline, but not as part of a for-loop). I would say
that is definitely worse.


You've probably missed that inline declartaion syntax is optional, not 
mandatory, and is intended to only be used where appropriate.


No I haven't...
But if I read someone else's code, I don't know what they did and what not.





3) As for duck typing:
for var i:= Func1 to Func2 do;


I think it is totally different from "normal" inline declarations and 
I don't like it actually.

Nice we agree on some point.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Ozz Nixon]

* Just to note there is a choice - not pitching one is better just, there
is someone doing it *
There is a choice of course... built using FPC. I wrote ModernPascal. We do
not focus on Windows support as much as other platforms FPC is available
for. Per grammar, MP2 (current build) was designed to make my efforts for
web development much easier...at the time, I was running Apache 2.2 at
home, and 2.4 at work, and constantly tripping over the include files for
my Apache Mods. (MP2 is now 18 years old, and very flexible with variables)
*NO GUI YET* (Lazarus and Delphi are great for that arena).

It can do
function xyz:boolean;
var
   a:byte;

begin
a:=1;
result:=(a=1);
end;

It can do
function xyz:boolean;
begin
   var a:=1;
   result:=(a=1);
end;

It also supports extremely short hand - for scripting:
// no program
// no begin
// just:
var a:=request.getMethod;
response.write(a);
// no end.

* We do not support Units in the style you expect, Modern Pascal's are
imported DLL/SO/Dynlibs, and we do not care to support Generics. Our
end-user base is under 1000 right now. But, we work on the product, with
the product, etc., every day, 7 days a week, for 18 years. Linux and Mac
binaries are on github.com/3fllc/modernpascal/ (windows binary has a bug in
it right now - when we upgraded to FPC 3.0.4 *I* broke something and have
not found it - but, not a fire as all of my end users are Linux or Mac.) --
tutorial.modernpascal.com for work in progress manual. We am very open to
designs, but, MP2 can still run 99% of Turbo Pascal source... except for
far, near, int, absolute, etc.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi,

20.02.2019 18:24, Dimitrios Chr. Ioannidis via fpc-devel:
[...]

 I'd like to see an example how this is less safe.


Well one of the answer in the Cantu blog has this ( which I changed to
lets say a "real world" relative big function ) :


How this example is different from e.g. using normally declared "I, J: 
Integer" and employing "J" as a loop variable? Wouldn't it do the same 
error anyway?



Thank you,

Regards,
Nikolai


var arr: array...

function Fuckup: boolean;
var I: Integer;
begin



<>  20 lines of code



   for var I := Low(arr) to High(arr) do
 if arr[I]. then
   break;



   <>  20 lines of code



   Result := (I<= High(arr));
end;

regards,
--
Dimitrios Chr. Ioannidis



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


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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi,

20.02.2019 17:56, Martin Frb:

1) "for" (and other) loops with a long body also exist.
So the problem is still there, if I encounter "i" in the middle of a


This is correct. Inline declaration will not be able to solve all 
problems in the galaxy, it could just help to relieve some of them.



1000 line for-loop, I still do not see its declaration. So far, no loss,
but no gain either.

2) Nested loops exist. If in the middle of such a 1000 line for-loop, I
want to declare another loop, then I need to find a free identifier for
that variable.  Today, I can do that by looking at the declaration on top of the
procedure (and afaik depending on context, the class fields).
With inline declaration, I have to find each of the 10 surrounding
for-loops, scattered over a 1000 lines (And that is ignoring any
variables declared inline, but not as part of a for-loop). I would say
that is definitely worse.


You've probably missed that inline declartaion syntax is optional, not 
mandatory, and is intended to only be used where appropriate.



But just my 2 cents.

Now do not tell me that those loops should be refactored, because they
are based on your statement that this is not always sensible.

3) As for duck typing:
for var i:= Func1 to Func2 do;


I think it is totally different from "normal" inline declarations and I 
don't like it actually.



Thank you,

Regards,
Nikolai


What if that is "QWord to int64(or at some future points changes to that)?
What will "i" then be? And why?
Or should that be a compile error? (Probably the best)



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


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

Re: [fpc-devel] "Blank slate" next version of FPC

[Giuliano Colla]

Il 20/02/2019 19:11, Nikolai Zhubr ha scritto:

Now it is getting even more curious. Admittedly I don't use C too much 
(and C++ even less so, approximately never), maybe that is why I do 
not understand your reasoning. Could you maybe give an example of such 
problematic inline declaration and its negative effect, in C++ at 
least? Honestly I can't imagine any.


Very easy: you read your code written some time before, or someone 
else's code, you miss the inline declaration, because it's buried in the 
code, and you mistake the variable with another one previously declared, 
in the outer scope.


I have just met such a situation: I ported from C++ to Pascal an 
algorithm for the computation of the kinematics of a Delta Robot, and I 
was badly bitten.
In that case you are just dealing with X,Y,Z coordinates, and 
Theta0,Theta1,and Theta2 angles, and you find, in the body of a 
procedure, some X,Y,Z or Theta which have global scope, and some which 
are just local to some smaller (but not too small) block and which are 
redeclared inline. Rather hard to tell them apart.
Redeclaring inline an index I, which you'll be then using a lot of 
times, is the best way to shoot you in the feet. Pascal encourages you 
to use I,J,K at first, then ii,jj,kk etc.


Moreover, using a modern tool such as Lazarus, you never need to scroll 
1000 lines to find a declaration: you just press alt+Up to go to the 
declaration of the symbol over the cursor, and Ctrl+H to go back to the 
line of code.


Keeping all declarations separated from code is just good programming 
practice. Mixing declaration and code is bad programming practice, IMO, 
and I appreciate Pascal for not supporting it.


Giuliano

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

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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi Sven,

20.02.2019 16:51, Sven Barth via fpc-devel:
[...]

Pascal is a language where declaration and use of variables is
separated.


I can understand that a language can (and should) try to follow some 
aesthetic tradition (which, btw, has already been horribly broken many 
times, imho, although it is not an excuse for further damage).
I can also understand that some immature syntactic sugar might introduce 
e.g. some ambiguities in parsing valid pascal code or some other 
specific unwanted problems, and if so, it can probably be demonstrated 
(to some extent at least, by an example or anyhow), and in such case 
indeed such new syntax should better be avoided.


However, the above statement about "Pascal as a language..." feels 
somehow strange. I'd say instead, that "Pascal as a language" was 
designed to be a tool to get job done efficiently, quickly, with 
confort, elegance, and superiority.



It makes it easy to see what variables are declared and what
type they are. Inline variables mess this up as a variable can be
declared somewhere inside the code.


Thats exactly what inline declaration does (when used reasonably): it 
makes it easy to see what variables are declared and what type they are. 
Well, at least, I see it as the intended purpose.



I use C++ to earn my living. I know why I'm not a fan of inline
variables as I've been biten by them often enough already.


Now it is getting even more curious. Admittedly I don't use C too much 
(and C++ even less so, approximately never), maybe that is why I do not 
understand your reasoning. Could you maybe give an example of such 
problematic inline declaration and its negative effect, in C++ at least? 
Honestly I can't imagine any.



Thank you,

Regards,
Nikolai



Regards,
Sven



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


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

Re: [fpc-devel] "Blank slate" next version of FPC

[Kostas Michalopoulos]

> and Niklaus Wirth might not throw a curse in us.

Considering we're talking about a dialect with three different
incompatible yet mostly overlapping object systems, i think the curse
has already been cast long long ago :-P.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Dimitrios Chr. Ioannidis via fpc-devel]

Hi,

Στις 20/2/2019 4:46 μ.μ., ο Paul van Helden έγραψε:
On Wed, Feb 20, 2019 at 4:35 PM Dimitrios Chr. Ioannidis via fpc-devel 
> wrote:


  Even if declaring variables as close as possible to where the
variable will be used ( debugging wise not readability wise )
leads to more correct code, the problem is to avoid the temptation
to use them in other places too.

Variables declared within a begin...end cannot be used elsewhere. 
(E.g. for var I:=0 to .. won't let you use I after the loop).


  AFAIK, one of Pascal's primary design goals is to won't let you
shoot yourself in the foot, and IMO that feature is not in that
direction.

 I'd like to see an example how this is less safe.


Well one of the answer in the Cantu blog has this ( which I changed to 
lets say a "real world" relative big function ) :


var arr: array...

function Fuckup: boolean;
var I: Integer;
begin



   <> 20 lines of code



  for var I := Low(arr) to High(arr) do
if arr[I]. then
  break;
 



  <> 20 lines of code



  Result := (I <= High(arr));
end;

regards,
--
Dimitrios Chr. Ioannidis

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

Re: [fpc-devel] "Blank slate" next version of FPC

[Martin Frb]

On 20/02/2019 15:46, Paul van Helden wrote:
On Wed, Feb 20, 2019 at 4:35 PM Dimitrios Chr. Ioannidis via fpc-devel 
> wrote:


  Even if declaring variables as close as possible to where the
variable will be used ( debugging wise not readability wise )
leads to more correct code, the problem is to avoid the temptation
to use them in other places too.

Variables declared within a begin...end cannot be used elsewhere. 
(E.g. for var I:=0 to .. won't let you use I after the loop)


for var i:=0 to 9 begin end;

That "i" is declared outside the begin end.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Martin Frb]

On 20/02/2019 14:36, Paul van Helden wrote:


So the argument against is: (1) split your long functions, because you 
should; and (2) Wirth didn't do it, so good it is not.


Long functions *might* be an indication of bad design, but you know, 
sometimes I have a long function that doesn't make sense to split.


Here is a good article about inline vars: 
http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html


What's not to like about for var I:=0 to Count-1 do.. ?

Or var MyDict:=TDictionary.Create;



1) "for" (and other) loops with a long body also exist.
So the problem is still there, if I encounter "i" in the middle of a 
1000 line for-loop, I still do not see its declaration. So far, no loss, 
but no gain either.


2) Nested loops exist. If in the middle of such a 1000 line for-loop, I 
want to declare another loop, then I need to find a free identifier for 
that variable.
Today, I can do that by looking at the declaration on top of the 
procedure (and afaik depending on context, the class fields).
With inline declaration, I have to find each of the 10 surrounding 
for-loops, scattered over a 1000 lines (And that is ignoring any 
variables declared inline, but not as part of a for-loop). I would say 
that is definitely worse.

But just my 2 cents.

Now do not tell me that those loops should be refactored, because they 
are based on your statement that this is not always sensible.


3) As for duck typing:
for var i:= Func1 to Func2 do;

What if that is "QWord to int64(or at some future points changes to that)?
What will "i" then be? And why?
Or should that be a compile error? (Probably the best)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Marco van de Voort]

(sorry for the pm, Paul, should have gone to list)

Op 2/20/2019 om 3:32 PM schreef Paul van Helden:
On Wed, Feb 20, 2019 at 3:52 PM Sven Barth via fpc-devel 
> wrote:



Pascal is a language where declaration and use of variables is
separated. It makes it easy to see what variables are declared and
what type they are. Inline variables mess this up as a variable
can be declared somewhere inside the code.


Now I'm curious. Can you point me to a resource where Pascal is 
defined such that the separation of declaration from use is a central 
tenet? I'm not sure, but I doubt I ever look at the variable 
declarations to help understand the rest of the code...


I'm not really a Pascal semantics guy, but I'll give it a try:

Pascal is block oriented. At the end of a block is always the opener of 
a new block (var, type, procedure, begin), encountering these tokens in 
the wrong are typically a warning that something is wrong.Now what is 
that marker at the end of an inline variable block ? Afaik there is 
none. The next can be any statement in any form, and you must 
disambiguate yourself if a variable declaration is meant or not.


From what I can see Embacadero avoids this by keeping all its examples 
one line, with the VAR on the same line. But Pascal is not line 
oriented, so this is also odd.


And keep in mind contrary to C/C++, Pascal is a limited lookahead parser.

So the whole feature reeks of Embacadero's desperation to keep bullet 
lists for new versions filled to keep people upgrading.


It has nothing to do with language design or better C/C++ syntax (*) or 
whatever. It is just a quick implementation in the hope to score some 
points with people that have participated in similar threads in 
Embarcadero groups. They just did a most minimal quick-and-dirty 
implementation and tossed on the feature matrix. Please upgrade.



(*) it is strange that people complain about scrolling 1000 lines up to 
see a declaration, but can effortlessly scan those 1000 lines for 
possible inline declarations without scrolling up.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Paul van Helden]

On Wed, Feb 20, 2019 at 4:35 PM Dimitrios Chr. Ioannidis via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:

>   Even if declaring variables as close as possible to where the variable
> will be used ( debugging wise not readability wise ) leads to more correct
> code, the problem is to avoid the temptation to use them in other places
> too.
>
Variables declared within a begin...end cannot be used elsewhere. (E.g. for
var I:=0 to .. won't let you use I after the loop).

>   AFAIK, one of Pascal's primary design goals is to won't let you shoot
> yourself in the foot, and IMO that feature is not in that direction.
>
 I'd like to see an example how this is less safe.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Dimitrios Chr. Ioannidis via fpc-devel]

Hi,

Στις 20/2/2019 3:36 μ.μ., ο Paul van Helden έγραψε:



> > 1. it makes it easier to see the whole picture just looking at
the loop
> > body, no need to scroll up; (The loop body might be just 10
lines of code,
> > whereas the whole containing function sometimes has 1000s)
> >
> > 2. it isoltates the scope of such variable(s), therefore
preventing some
> > sorts of accidental misuse outside of e.g. the containing loop
(which still
> > do happen to me ocasionally in Pascal).
>
> I've already tried to make these points, nobody seems to buy
it.  IIRC
> Michael (vC) said that functions shouldn't be that long, so then
it's
> not a problem (perhaps his world is perfect, but mine certainly
isn't).

Anyone can split a function in many others. It's not so difficult and,
actually, it should be done.

> I'm mostly more interested in limiting the scope to prevent
accidental
> use, like you.  It can also offer more fine grained control of where
> managed variables get freed.

Try to see restrictions as a good thing.
In this case, which Pascal doesn't allow to declare inline variables,
you must split big functions, which has many local variables, in
others to have a better understanding of the algorithm. At the end,
you might have a better design and reuse of the code. Everybody wins:
you, your code, Pascal team - as they don't need to change the
compiler - and Niklaus Wirth might not throw a curse in us.


O dear, now I've dunnit...

So the argument against is: (1) split your long functions, because you 
should; and (2) Wirth didn't do it, so good it is not.


  Even if declaring variables as close as possible to where the 
variable will be used ( debugging wise not readability wise ) leads to 
more correct code, the problem is to avoid the temptation to use them in 
other places too.


  AFAIK, one of Pascal's primary design goals is to won't let you shoot 
yourself in the foot, and IMO that feature is not in that direction.


--

Dimitrios Chr. Ioannidis

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

Re: [fpc-devel] "Blank slate" next version of FPC

[Paul van Helden]

On Wed, Feb 20, 2019 at 3:52 PM Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:

>
> Pascal is a language where declaration and use of variables is separated.
> It makes it easy to see what variables are declared and what type they are.
> Inline variables mess this up as a variable can be declared somewhere
> inside the code.
>

Now I'm curious. Can you point me to a resource where Pascal is defined
such that the separation of declaration from use is a central tenet? I'm
not sure, but I doubt I ever look at the variable declarations to help
understand the rest of the code...

To me it seems like an artificial limitation which probably made compiler
development easier (or compilation faster?). Yet most other languages
didn't see the need for this limitation.

(I see Pascal as a C-like language with superior readability. I want the
speed of C AND be able to easily understand the code).


> I use C++ to earn my living. I know why I'm not a fan of inline variables
> as I've been biten by them often enough already.
>
> Can you provide an example of how inline variables can bite?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Marcos Douglas B. Santos]

On Wed, Feb 20, 2019 at 10:25 AM Henry Vermaak  wrote:
>
> On Wed, Feb 20, 2019 at 09:47:20AM -0300, Marcos Douglas B. Santos
> wrote:
> > On Wed, Feb 20, 2019 at 8:32 AM Henry Vermaak
> >  wrote:
> > > I'm mostly more interested in limiting the scope to prevent
> > > accidental use, like you.  It can also offer more fine grained
> > > control of where managed variables get freed.
> >
> > Try to see restrictions as a good thing.  In this case, which Pascal
> > doesn't allow to declare inline variables, you must split big
> > functions, which has many local variables, in others to have a better
> > understanding of the algorithm. At the end, you might have a better
> > design and reuse of the code. Everybody wins: you, your code, Pascal
> > team - as they don't need to change the compiler - and Niklaus Wirth
> > might not throw a curse in us.
>
> I don't have many big functions and I've missed scoped variables in
> Pascal since the early 1990s.  It's been standard good practice in
> software engineering for decades and all the languages I work with
> support it because it's a good idea, not because it's some newfangled
> fad.
>
> But big functions happen in the real world.  The fpc compiler source has
> dozens of extremely long functions.  Lazarus too.  I think the windproc
> function in the win32 interface is more than 700 lines (look at
> TWindowProcHelper.DoWindowProc).

Yes, you're right. Big functions happen in the real world...
But it doesn't mean those functions are well written only because they exists.
IMHO, instead of support those functions, let use a better design to
create them.

regards,
Marcos Douglas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Dimitrios Chr. Ioannidis via fpc-devel]

Hi,

Στις 20/2/2019 3:25 μ.μ., ο Henry Vermaak έγραψε:

On Wed, Feb 20, 2019 at 09:47:20AM -0300, Marcos Douglas B. Santos
wrote:

On Wed, Feb 20, 2019 at 8:32 AM Henry Vermaak
 wrote:

I'm mostly more interested in limiting the scope to prevent
accidental use, like you.  It can also offer more fine grained
control of where managed variables get freed.

Try to see restrictions as a good thing.  In this case, which Pascal
doesn't allow to declare inline variables, you must split big
functions, which has many local variables, in others to have a better
understanding of the algorithm. At the end, you might have a better
design and reuse of the code. Everybody wins: you, your code, Pascal
team - as they don't need to change the compiler - and Niklaus Wirth
might not throw a curse in us.

I don't have many big functions and I've missed scoped variables in
Pascal since the early 1990s.  It's been standard good practice in
software engineering for decades and all the languages I work with
support it because it's a good idea, not because it's some newfangled
fad.

But big functions happen in the real world.  The fpc compiler source has
dozens of extremely long functions.  Lazarus too.  I think the windproc
function in the win32 interface is more than 700 lines (look at
TWindowProcHelper.DoWindowProc).


Well, people used to ( apparently still do ) write functions that were 
hundreds, even thousands of lines long and they used to write them in 
plain text editors (think Notepad) without the kind of support Lazarus 
provided. In that environment, declaring a variable hundreds of lines 
away from where it was used meant that the person reading


if (flag) limit += factor;

didn't have a lot of clues about what flag, limit and factor were. 
Naming conventions like Hungarian notation were adopted to help with 
this, and so were rules like declaring things close to where they are 
used. Of course, these days, it's all about refactoring, and functions 
are generally less than a page long, making it hard to get very much 
distance between where things are declared and where they are used. 
You're operating in a range of 0-20 and quibbling that maybe 7 is ok in 
this particular instance, while the guy(s) who made the rule would have 
LOVED to get 7 lines away and was trying to talk someone down from 700. 
And on top of that, in Lazarus, you can mouse over anything and see its 
type, is it a member variable, and so on. That means the need to see the 
line declaring it is lessened.


( not mine but I agree 100% ).


--

Dimitrios Chr. Ioannidis

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

Re: [fpc-devel] "Blank slate" next version of FPC

[Sven Barth via fpc-devel]

Am Mi., 20. Feb. 2019, 12:07 hat Nikolai Zhubr 
geschrieben:

> So I'm just wondering, what is wrong with such approach that it is
> considered so harmfull for Pascal? (Not talking here about possible
> excessive complexity of actual implementation in compiler, and not
> talking about the exact syntax chosen for that, just the idea as a whole)
>

Pascal is a language where declaration and use of variables is separated.
It makes it easy to see what variables are declared and what type they are.
Inline variables mess this up as a variable can be declared somewhere
inside the code.
I use C++ to earn my living. I know why I'm not a fan of inline variables
as I've been biten by them often enough already.

Regards,
Sven

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

Re: [fpc-devel] "Blank slate" next version of FPC

[Paul van Helden]

>
>
> > > 1. it makes it easier to see the whole picture just looking at the loop
> > > body, no need to scroll up; (The loop body might be just 10 lines of
> code,
> > > whereas the whole containing function sometimes has 1000s)
> > >
> > > 2. it isoltates the scope of such variable(s), therefore preventing
> some
> > > sorts of accidental misuse outside of e.g. the containing loop (which
> still
> > > do happen to me ocasionally in Pascal).
> >
> > I've already tried to make these points, nobody seems to buy it.  IIRC
> > Michael (vC) said that functions shouldn't be that long, so then it's
> > not a problem (perhaps his world is perfect, but mine certainly isn't).
>
> Anyone can split a function in many others. It's not so difficult and,
> actually, it should be done.
>
> > I'm mostly more interested in limiting the scope to prevent accidental
> > use, like you.  It can also offer more fine grained control of where
> > managed variables get freed.
>
> Try to see restrictions as a good thing.
> In this case, which Pascal doesn't allow to declare inline variables,
> you must split big functions, which has many local variables, in
> others to have a better understanding of the algorithm. At the end,
> you might have a better design and reuse of the code. Everybody wins:
> you, your code, Pascal team - as they don't need to change the
> compiler - and Niklaus Wirth might not throw a curse in us.
>
>
O dear, now I've dunnit...

So the argument against is: (1) split your long functions, because you
should; and (2) Wirth didn't do it, so good it is not.

Long functions *might* be an indication of bad design, but you know,
sometimes I have a long function that doesn't make sense to split.

Here is a good article about inline vars:
http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html

What's not to like about for var I:=0 to Count-1 do.. ?

Or var MyDict:=TDictionary.Create;

Marcos says restrictions are good. The above restricts the number of lines
of code while being just as (or more) readable!
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Henry Vermaak]

On Wed, Feb 20, 2019 at 09:47:20AM -0300, Marcos Douglas B. Santos
wrote:
> On Wed, Feb 20, 2019 at 8:32 AM Henry Vermaak
>  wrote:
> > I'm mostly more interested in limiting the scope to prevent
> > accidental use, like you.  It can also offer more fine grained
> > control of where managed variables get freed.
> 
> Try to see restrictions as a good thing.  In this case, which Pascal
> doesn't allow to declare inline variables, you must split big
> functions, which has many local variables, in others to have a better
> understanding of the algorithm. At the end, you might have a better
> design and reuse of the code. Everybody wins: you, your code, Pascal
> team - as they don't need to change the compiler - and Niklaus Wirth
> might not throw a curse in us.

I don't have many big functions and I've missed scoped variables in
Pascal since the early 1990s.  It's been standard good practice in
software engineering for decades and all the languages I work with
support it because it's a good idea, not because it's some newfangled
fad.

But big functions happen in the real world.  The fpc compiler source has
dozens of extremely long functions.  Lazarus too.  I think the windproc
function in the win32 interface is more than 700 lines (look at
TWindowProcHelper.DoWindowProc).

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

Re: [fpc-devel] "Blank slate" next version of FPC

[Marcos Douglas B. Santos]

On Wed, Feb 20, 2019 at 8:32 AM Henry Vermaak  wrote:
>
> On Wed, Feb 20, 2019 at 02:26:20PM +0300, Nikolai Zhubr wrote:
> > 20.02.2019 13:21, Sven Barth via fpc-devel:
> > [...]
> > >And we don't agree here. For us inline variables is one of the most
> > >horrid if not *the* most horrid thing Embarcadero could have done to
> > >Object Pascal.
> >
> > Could you elaborate a bit about it?
> > While I'm not really sure what they have done exactly (not using latest
> > Delphi and probably not going to), I've somehow got very used to (and
> > confortable with) Java's inline declarations, especially "for (int i = 0;
> > )" and similar constructs, and now I find myself doing this way all the
> > time, because:
> >
> > 1. it makes it easier to see the whole picture just looking at the loop
> > body, no need to scroll up; (The loop body might be just 10 lines of code,
> > whereas the whole containing function sometimes has 1000s)
> >
> > 2. it isoltates the scope of such variable(s), therefore preventing some
> > sorts of accidental misuse outside of e.g. the containing loop (which still
> > do happen to me ocasionally in Pascal).
>
> I've already tried to make these points, nobody seems to buy it.  IIRC
> Michael (vC) said that functions shouldn't be that long, so then it's
> not a problem (perhaps his world is perfect, but mine certainly isn't).

Anyone can split a function in many others. It's not so difficult and,
actually, it should be done.

> I'm mostly more interested in limiting the scope to prevent accidental
> use, like you.  It can also offer more fine grained control of where
> managed variables get freed.

Try to see restrictions as a good thing.
In this case, which Pascal doesn't allow to declare inline variables,
you must split big functions, which has many local variables, in
others to have a better understanding of the algorithm. At the end,
you might have a better design and reuse of the code. Everybody wins:
you, your code, Pascal team - as they don't need to change the
compiler - and Niklaus Wirth might not throw a curse in us.

regards,
Marcos Douglas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Marcos Douglas B. Santos]

On Wed, Feb 20, 2019 at 8:07 AM Nikolai Zhubr  wrote:
>
> Hi all,
>
> 20.02.2019 13:21, Sven Barth via fpc-devel:
> [...]
> > And we don't agree here. For us inline variables is one of the most
> > horrid if not *the* most horrid thing Embarcadero could have done to
> > Object Pascal.
>
> Could you elaborate a bit about it?
> While I'm not really sure what they have done exactly (not using latest
> Delphi and probably not going to), I've somehow got very used to (and
> confortable with) Java's inline declarations, especially "for (int i =
> 0; )" and similar constructs, and now I find myself doing this way
> all the time, because:
>
> 1. it makes it easier to see the whole picture just looking at the loop
> body, no need to scroll up; (The loop body might be just 10 lines of
> code, whereas the whole containing function sometimes has 1000s)

The problem is that you want to see an "i" variable that is index of the loop?
The same construction was good for years, but now, as other languages
has that feature, Object Pascal is obsolete and should add all that
"new features"?

If a function has 1000 lines is a problem in the design, not in the
language - in fact, doesn't matter the language in that case.

> 2. it isoltates the scope of such variable(s), therefore preventing some
> sorts of accidental misuse outside of e.g. the containing loop (which
> still do happen to me ocasionally in Pascal).

Again, if you has many variables into a method, is a problem in the
design. You must split the code in other methods.
If you have blank lines inside a method, this is another case to split...

regards,
Marcos Douglas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Marcos Douglas B. Santos]

On Wed, Feb 20, 2019 at 7:21 AM Sven Barth via fpc-devel
 wrote:
>
> And we don't agree here. For us inline variables is one of the most horrid if 
> not *the* most horrid thing Embarcadero could have done to Object Pascal.

+1
Even this isn't break compatibility with past code, it turns the
language a mess.
I could say the same for others "new features", but it isn't the place.

regards,
Marcos Douglas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] "Blank slate" next version of FPC

[Henry Vermaak]

On Wed, Feb 20, 2019 at 02:26:20PM +0300, Nikolai Zhubr wrote:
> 20.02.2019 13:21, Sven Barth via fpc-devel:
> [...]
> >And we don't agree here. For us inline variables is one of the most
> >horrid if not *the* most horrid thing Embarcadero could have done to
> >Object Pascal.
> 
> Could you elaborate a bit about it?
> While I'm not really sure what they have done exactly (not using latest
> Delphi and probably not going to), I've somehow got very used to (and
> confortable with) Java's inline declarations, especially "for (int i = 0;
> )" and similar constructs, and now I find myself doing this way all the
> time, because:
> 
> 1. it makes it easier to see the whole picture just looking at the loop
> body, no need to scroll up; (The loop body might be just 10 lines of code,
> whereas the whole containing function sometimes has 1000s)
> 
> 2. it isoltates the scope of such variable(s), therefore preventing some
> sorts of accidental misuse outside of e.g. the containing loop (which still
> do happen to me ocasionally in Pascal).

I've already tried to make these points, nobody seems to buy it.  IIRC
Michael (vC) said that functions shouldn't be that long, so then it's
not a problem (perhaps his world is perfect, but mine certainly isn't).

I'm mostly more interested in limiting the scope to prevent accidental
use, like you.  It can also offer more fine grained control of where
managed variables get freed.

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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi all,

20.02.2019 13:21, Sven Barth via fpc-devel:
[...]

And we don't agree here. For us inline variables is one of the most
horrid if not *the* most horrid thing Embarcadero could have done to
Object Pascal.


Could you elaborate a bit about it?
While I'm not really sure what they have done exactly (not using latest 
Delphi and probably not going to), I've somehow got very used to (and 
confortable with) Java's inline declarations, especially "for (int i = 
0; )" and similar constructs, and now I find myself doing this way 
all the time, because:


1. it makes it easier to see the whole picture just looking at the loop 
body, no need to scroll up; (The loop body might be just 10 lines of 
code, whereas the whole containing function sometimes has 1000s)


2. it isoltates the scope of such variable(s), therefore preventing some 
sorts of accidental misuse outside of e.g. the containing loop (which 
still do happen to me ocasionally in Pascal).


So I'm just wondering, what is wrong with such approach that it is 
considered so harmfull for Pascal? (Not talking here about possible 
excessive complexity of actual implementation in compiler, and not 
talking about the exact syntax chosen for that, just the idea as a whole)



Thank you,

Regards,
Nikolai


Regards,
Sven



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


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

Re: [fpc-devel] "Blank slate" next version of FPC

[Sven Barth via fpc-devel]

Am Mi., 20. Feb. 2019, 08:36 hat Paul van Helden 
geschrieben:

> and FPC's goal to remain Delphi-compatible.
>>>
>>>
>>> So are inline variables coming soon?
>>> http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html
>>>
>>
>> We have already decided internally that this feature is where we draw the
>> line. We won't implement it and we are also inclined to say "patches *not*
>> welcome" for that.
>>
>> Regards,
>> Sven
>>
>>
> To add a dissenting voice, from someone who has followed FPC development
> for more than 10 years and used to be very exited about FPC/Lazarus...
>
> Sven's statement just about seals it for me. So then FPC's main goal isn't
> Delphi compatibility any more? I for one will use inline variable
> declarations and therefore say goodbye to FPC. Not to start a pro-vs-con
> discussion in this thread, but personally I see only advantages in more
> fine-grained control of variable scope. (Plus it has been irritating me for
> more than 25 years to go to the top to declare variables [and no,
> auto-declarations by the IDE doesn't fix it for me; e.g. if generics are
> good, why not duck typing?]). Yes, Embarcadero has done some horrid things
> to the language, but I don't see this as one of them. As a big fan of the
> Pascal language, I'd rather break compatibility and see the language evolve
> than the stoic attitude of the core devs as seen on this list. (And inline
> vars doesn't break anything!) If Oxygene was open source and (CPU) native,
> I wouldn't even been reading this list...
>

And we don't agree here. For us inline variables is one of the most horrid
if not *the* most horrid thing Embarcadero could have done to Object
Pascal.

Regards,
Sven

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

Re: [fpc-devel] re "Blank slate" next version of FPC

[Marco van de Voort]

Op 2/17/2019 om 5:58 PM schreef Fred van Stappen:

Am 17.02.19 um 04:48 schrieb Marco van de Voort
> Martin was a loner kind of guy, he did the most of the MSEGUI etc 
> projects alone too.

Did you know him personally?


I meant the loner label as relating to programming only. It is not 
necessarily a negative thing, more stating a close-to-a-fact, that he 
was not really a collaborative/team programmer



And no, I didn't know him personally.



Martin was a generous guy, always ready to help people.


I was referring more to the fact that he worked alone on most of his 
code. He was not a teamplayer. One does not exclude the other.



I wrote to the notice of him passing away that he did work hard on the 
2.2.0 objpas/classes rewrite (the component streaming)




And when he gave help/code, it was always perfect code, without any bug or 
memory-leak (not like you Guru-Marco).



Cheap and baseless dig.



Also, he was open to discussion, I did work on some projects with him.


There was communication too in the time he worked on component streaming 
in FPC. But that is something else from working in a team as more or 
less equals, without him specifying all the rules down to how symbols 
should be mangled (-ty). I never saw that, but maybe you can prove me wrong.


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