Inline vars / Re: Conditional ternary operators For FreePascal?

[BeniBela]

In Lazarus, there is no problem when entering an expression with a new variable. You don't need to navigate elsewhere in the code for variable declaration; press Ctrl+Shift+C and continue working in the same spot. 

you cannot rely on that

when I started to use  new FPC syntaxes, it completely broke.

the most annoying recent thing  is with a generic object that has an enumerator. If I use  Ctrl+Shift+C in the for..in..do  loop, Lazarus only tells me, there is no enumerator.

and the generic ones often went wrong and it picks the wrong type. Like there is a function returning T, and Lazarus creates a variable of type T. But actually it comes from SomeClass<T> and there is a specialize SomeClass<string> somewhere and it should have created a variable of type string.

I think I also had problems when it didn't recognize any type helpers

sometimes it breaks because something else in the code is not understood. if a unit is not found, it completes nothing, even if the unit has no relevance at the current location.

and for literal integers, this creates an "integer" variable. that is almost always wrong. I only need SizeInt. Some people define their own integer types and only use their types. They never use integer. (like Bero does "type TFLREInt32={$if declared(Int32)}Int32{$else}LongInt{$ifend};")
 

[BeniBela]

One more reason, not to inline.
Even (or maybe especially) if you have the most basic editor (on tools to help with anything).

Then depending on workflow, style and .... it may save between a little and a moderate amount of keystrokes to declare the var inline.

But, that is only when you first write the code. To decide your total cost (plus/minus) you need to consider the work for maintaining that code later. Maintaining in the same basic editor, with the same lack of tools.

So you have inline

Code: Pascal  [Select][+][-]

1. procedure xyz,
2. begin
3.   {...}
4.   SetFoo(1); // some comment about foo
5.   {...}
6.   var foo: integer := 0;
7.   {...}
8.   if bar then foo := 1;
9.   {...}
10.   foo := GetFoo();
11.  

Now GetFoo changes to int64 or cardinal. You need to change the code.

On the contrary, that is exactly the reason why we need all the new features. With ternary operators, inline vars and type inference, you write this as:

Code: Pascal  [Select][+][-]

1. procedure xyz,
2. begin
3.   {...}
4.   SetFoo(1); // some comment about foo
5.   {...}
6.   var foo := if bar then 1 else GetFoo();  
7.  

then foo has the same type as GetFoo.

and if the type of GetFoo changes, then the type of foo changes automatically and you never have to change the code anymore

[Martin_fr]

On the contrary, that is exactly the reason why we need all the new features. With ternary operators, inline vars and type inference, you write this as:

Code: Pascal  [Select][+][-]

1. procedure xyz,
2. begin
3.   {...}
4.   SetFoo(1); // some comment about foo
5.   {...}
6.   var foo := if bar then 1 else GetFoo();  
7.  

then foo has the same type as GetFoo.

and if the type of GetFoo changes, then the type of foo changes automatically and you never have to change the code anymore

There wasn't an else block.

Code: Pascal  [Select][+][-]

1.   var foo: integer := 0;

was unconditionally.

Then there was other code...., then there was maybe a ":= 1", and other code, ....



Also, omitting the ": integer" (Aka duck typing), is a new topic.

True, if you want duck typing, then you do need inline (since you can't duck type a variable from a function is the "var" block).

But then to use duck typing as argument, we first need to agree its a good idea (which I fiercely oppose). One of the really really major points for Pascal is that it is (very much mostly) strong typed. Do not destroy that.

Just one example (after that I will not reply to duck typing in this thread). Make the change

Code: Pascal  [Select][+][-]

1. program Project1;{$mode objfpc} {$R-}{$Q-}
2. type
3.   TNum = integer;
4.   //TNum = cardinal;
5.  
6. function cnt: TNum; begin Result := 0; end;
7.  
8. //var i: TNum;
9. var i: integer;
10. begin
11.   for i := 0 to cnt - 1 do writeln(i);
12.   readln;
13. end.
14.  

So long as "i: integer" it works fine. I can change the type of "cnt".
If i follows that type, and it becomes cardinal, then the loop will do a lot of work.

[linuxfan]

Just a few final thoughts.

One should assume that relevant tools are used to code. At least for me, it has no sense to use vim or notepad to write in Lazarus, when Lazarus starts quickly, is fast, and has everything needed and even more. Of course, if a language lacks a feature, an editor will not solve, perhaps only mitigate.

Regarding duck typing, the IDE Ctrl+Shift+C *does* duck typing, and even the CONST sections of a pascal program **is** duck typing. It cannot be so bad, if used when useful and avoided when it is ambiguous. Compare Java and Python. The former is very verbose and distracting with all those type declarations and casts. I believe it has too little duck typing. In Python, you never know what a variable contains: only in an assignment you have a real clue about the type of the variable.

About inlining variables, a big advantage exist, which is the contrary of what Martin said. If I decide to change type of a function, or a variable, I search then the whole project for every occurence of that function or variable (everyone does so, right?).
Change func(), search and find this:

Code: Pascal  [Select][+][-]

1. // classic VAR section:
2. theindex := func;  // theindex is declared elsewhere, how was it declared?
3.  
4. // inlined var:
5. var theindex: integer = func;  // case 1: I comfortably see *now* the type of the variable
6. var theindex := func;  // case 2: even better. It cannot be wrong (in this case) thanks to duck typing
7.  

Of course a grain of salt has to be used: inline variables when useful, choose long and descriptive names when useful, use duck typing when it is not ambiguous, perform a final review of a newly written function before trying, et cetera. The problem of Java and Python is that they chose a way, and there is no escape (well, python made something toward optional static typing, don't know the current status).

If freepascal implemented inline vars, it would not force them (I hope!); that is the key.

From time to time I browse the internet to see comparison of languages, and what other think about pascal or C or whatever. Pascal is hated by a lot of people, and a motivation is its verbosity. Are people too lazy to type begin and end, and procedure etc? Maybe. I love pascal exactly for that: C, with all its symbols hurts my eyes. Some people (me too) love pascal for its clear syntax, even if a little verbose. But I suspect the big obstacle, in the end, is the rigidity a little like cobol. Programmers have other things to do, than to keep the compiler happy. The code is written once, then read many times and modified many times. A good language should help this process, and good features like inlining, and good editors, can help if used in the right manner.

[440bx]

I've said it before and I'll say it again... C/C++'s and Delphi's implementation of inline variables is "deficient".

In spite of that, they are extremely useful in the writing of better, cleaner code.  As it is currently, variables that are simply throw-away variables have to be declared along with variables that are crucial to the code's purpose.  It shouldn't be that way.   Those throw away variables should be local to the scope in which they are active (which is NOT the entire function.)

The lack of inline variables causes at least 2 problems, throw away variables are global to the entire function/procedure when they shouldn't be (as mentioned above.)  They also encourage programmers to not simplify complex expressions, i.e, if an expression can be broken into n separate, clear pieces that are then combined into a final result, that's much more desirable than a single huge expression caused mostly by the reluctance of the programmer to create n scope-local throw away variables to simplify the expression or, what might be even worse (and quite common in Pascal), break the expression into multiple functions, forcing the programmer to have to "jump" to those functions to find out what they do.

A consequence of that is that compiler has a harder time optimizing code because, quite often, throw away variables are re-used, e.g, some variable "i" which is used in multiple places.  The compiler has to figure out that the uses are unrelated in order to optimize code.

Anyone who reads a fair amount of C code is quite aware of, not only the convenience but, the advantages of having inline variables.

All that said, I wish they were properly implemented.  Not likely to happen since it looks like they won't even be implemented the C/C++/Delphi way.

[Martin_fr]

If freepascal implemented inline vars, it would not force them (I hope!); that is the key.

Everything that is added, is always forced on everyone.
I may not have to type it myself. But I can not shut the world out, so I will have to read it, because someone else used it in their code.

Regarding duck typing, the IDE Ctrl+Shift+C *does* duck typing, and even the CONST sections of a pascal program **is** duck typing. It cannot be so bad, if used when useful and avoided when it is ambiguous.

Both are different.

Codetools is a once off. And hopefully checked once by the user. It does not follow and break the compiled app, if something else changes in type. (see example before)

"for" loops are one of the biggest examples for inline vars (including those with duck typing) => And the example shows how vulnerable it makes the resulting code.

Sure, if the "cnt" function was cardinal to start with, codetools would create a loop counter of type cardinal => but at least that would be declared on the variable. I get a chance to notice it. If the function was in another unit, I would never notice it, until I spent good time to debug the app because it doesn't work (if I noticed, before I shipped to the end user).

And if, that feature is added, then every bit of 3rd party code that I ever used becomes less reliable, because the author may have used that feature, and it may have introduced bugs, that you couldn't have before. (And that is for all the examples I gave, not just inline+duck, but also inline on its own)


"const" declarations are indeed duck typed (though they can be declared with type too / as real non-writeable constant / but that is not the point).
It be possible to start a discussion on how or if they differ (due to what input they can take).....
But, lets assume the worst (i.e. they don't differ) => would that be a reason to extend the problem, and make the problem even bigger?

Compare Java and Python. The former is very verbose and distracting with all those type declarations and casts. I believe it has too little duck typing. In Python, you never know what a variable contains: only in an assignment you have a real clue about the type of the variable.

Yes, python (as a lot of script languages) doesn't have much of "type"s.
But then, I wouldn't use it for the same purposes that I would use a languages with type system for.

I know there are huge apps (server side apps) in JS. But then someone invented typescript. (though looking at how much its used, lots of people prefer the uncertainty of JS).

I always am glad, that when I refactor or update code, the compiler will give me errors if I screw up. So much easier than to test and debug everything. (and search usually returns to many locations, and skips some too).
Of course its not a 100%. Hardcoded typecasts can still screw me. But then again, just because it isn't perfect, doesn't give a reason to intentionally make it worse.

About inlining variables, a big advantage exist, which is the contrary of what Martin said. If I decide to change type of a function, or a variable, I search then the whole project for every occurence of that function or variable (everyone does so, right?).
Change func(), search and find this:

Code: Pascal  [Select][+][-]

1. // classic VAR section:
2. theindex := func;  // theindex is declared elsewhere, how was it declared?
3.  
4. // inlined var:
5. var theindex: integer = func;  // case 1: I comfortably see *now* the type of the variable
6. var theindex := func;  // case 2: even better. It cannot be wrong (in this case) thanks to duck typing
7.  

You have actually seen and understood the example I gave?

Yes, if I change the return type of a function (or property, or...) then I must update my code by hand. And, yes that means I have to go a few steps to find the places where I have to do so. But at least, I get to see, if such an update will screw me over.

If it is duck typed, then I just get screwed.

Btw, your example is flawed

Code: Pascal  [Select][+][-]

1. [quote]theindex := func;  // theindex is declared elsewhere, how was it declared?[/quote]

Even if "theindex" was declared with duck typing, since it is immutable, that could easily have been at some earlier point inside that function code body. It may then just be assigned a new value from that function.

So if we take that example of yours (and ignore my other warnings), then...
- in some case you will now find "func" and save the very little time of going to the "var" declaration block.
- but, in other case, you will find it, and the inline-var (plus duck typing) will be somewhere else in the function body

So the first save a few seconds, the second looses them again, because now finding the random pos where that var is declared, that takes more time than finding the "var" block.
But even worse.

Code: Pascal  [Select][+][-]

1. procedure bar;
2. begin
3.   {...}
4.   var foo := xyz();
5.   {...}
6.   foo := func();
7.   {...}

Now when you change the type of "func" (and assuming you somehow realize it breaks the above code / which may take some time to debug...), but assuming you find the "foo := func()" line in the same time as you would do by a search.
Then
- you must find the "var foo" line, hidden somewhere in a block of code
- you must look up the type of "xyz"

How is that an improvement?

Of course a grain of salt has to be used: inline variables when useful, choose long and descriptive names when useful, use duck typing when it is not ambiguous, perform a final review of a newly written function before trying, et cetera.

Good naming is key in any case....

How to you know that it neither is, nor will in future ever be ambiguous?

Again, I refer to my earlier "for i := 0 to cnt()" loop example => would you have though that this is ambiguous?
And then what is not ambiguous?

And when you refactor code, how much time to you spent to re-check every duck typed declaration?

duck typing is borrowing time, at an extremely high interest rate. You may be lucky (or not) and pay day may not arrive for a long time. But eventually it will (even if after years), and when you get that bug that makes it pay day, you can easily loose way more that the few seconds you saved by not specifying the type to start with.

(well, python made something toward optional static typing, don't know the current status).

See my above typescript comment. Apparently more and more people who started on type-less or duck typed code, are getting bitten and start wanting the protection of types. (even if there are masses remaining who don't know yet).

Why should we want to reduce that protection in Pascal?
And again, there is no "you don't have to use it".

From time to time I browse the internet to see comparison of languages, and what other think about pascal or C or whatever. Pascal is hated by a lot of people, and a motivation is its verbosity. Are people too lazy to type begin and end, and procedure etc? Maybe. I love pascal exactly for that:

And having proper manually typed vars, is very much a most important part of this verbosity. (and also way more/better than just verbosity)

Programmers have other things to do, than to keep the compiler happy. The code is written once, then read many times and modified many times. A good language should help this process, and good features like inlining, and good editors, can help if used in the right manner.

Proper typing (not duck typing) has nothing to do with keeping the compiler happy. (That may have been one of many considerations several decades ago, but that is ancient history)

All the reasons I gave against inline-vars (with and without duck typing) are to help the programmer with exactly the tasks you mention.

Sure, having to declare a variable Pascal style, costs a tiny bit of time. But that is an investment towards better code. It pays out in the end.

As for the not duck-typing (regardless of inline or up front declaration), that is so helpful that even (some) JS users want it and have typescript now. (And according to you, Python users too).

If even those languages move away from duck typing (even if they can't for compatibility abandon it), then that is really telling a story.

[Thaddy]

In spite of that, they are extremely useful in the writing of better, cleaner code.  As it is currently, variables that are simply throw-away variables have to be declared along with variables that are crucial to the code's purpose.  It shouldn't be that way.   Those throw away variables should be local to the scope in which they are active (which is NOT the entire function.)

That's about the same as I proposed with my index implicit var:

Code: Pascal  [Select][+][-]

1. for index in { block1 } do for index{ block2 } do for index:=1{$block3 to do..

has three defined blocks for which the compiler already knows the context. You don't even need the contrived for var x in do because index as a reserved var is implied.
No i,j,k necessary!

[Martin_fr]

The lack of inline variables causes at least 2 problems, throw away variables are global to the entire function/procedure when they shouldn't be (as mentioned above.)  They also encourage programmers to not simplify complex expressions, i.e, if an expression can be broken into n separate, clear pieces that are then combined into a final result, that's much more desirable than a single huge expression caused mostly by the reluctance of the programmer to create n scope-local throw away variables to simplify the expression or, what might be even worse (and quite common in Pascal), break the expression into multiple functions, forcing the programmer to have to "jump" to those functions to find out what they do.

As I shown before: scoping could be done with variables declared up front.

As for readability, the location of where a variable is declared shouldn't force the user to check how long the current code block will go on.

If declared inline then I must ask:
Am I at all in a nested begin..end? (Is the indentation correct, or maybe my tab settings screwed it up?).
If I am not in a nested begin..end then this variable may be used down to the very end of the function...

If a variable is meant to be "less valuable" (throwaway) that can be expressed by its name.
And also, by it being noticeable declared as "scoped"

Code: Pascal  [Select][+][-]

1. procedure foo;
2. {label loop1;}
3. var
4.   TmpBarIndex: integer scoped loop1;
5. begin
6. end;

Now that tells everything, doesn't it?
The name TmpBarIndex already says, that it is some temp helper.
And it also tells me that it is for a specific scope only.

I don't know how many people will write longer expressions, only (and really only) because declaring a variable is to much effort.

Primary reason I have encountered (but of course that is not representative) is the space a multi line expression would take. Forcing scrolling to read more surrounding code.

And if it is that, then inline declarations make the lines longer (and therefore may force extra linebreaks), and therefore could actually reduce the willingness to split long expressions...

But as I said, I don't have representative statistics on why people do long expressions... Not sure if you have such representative data?

[Thaddy]

Code: Pascal  [Select][+][-]

1. procedure foo;
2. {label loop1;}
3. var
4.   TmpBarIndex: integer scoped loop1;
5. begin
6. end;

How is that conceptionally different from?:

Code: Pascal  [Select][+][-]

1. procedure deranged;
2. type range = 20..30;{label loop1;}
3. var i:integer;
4. begin
5.   for i in range do writeln(i);
6. end;
7.  
8. begin
9.   deranged;
10. end.

Which is already supported.

[BeniBela]

But then to use duck typing as argument, we first need to agree its a good idea (which I fiercely oppose). One of the really really major points for Pascal is that it is (very much mostly) strong typed. Do not destroy that.

Just one example (after that I will not reply to duck typing in this thread). Make the change

Code: Pascal  [Select][+][-]

1. program Project1;{$mode objfpc} {$R-}{$Q-}
2. type
3.   TNum = integer;
4.   //TNum = cardinal;
5.  
6. function cnt: TNum; begin Result := 0; end;
7.  
8. //var i: TNum;
9. var i: integer;
10. begin
11.   for i := 0 to cnt - 1 do writeln(i);
12.   readln;
13. end.
14.  

So long as "i: integer" it works fine. I can change the type of "cnt".
If i follows that type, and it becomes cardinal, then the loop will do a lot of work.

In this case, the problem is again "var i: TNum;"

It should work fine with "var i := cnt - 1"

FreePascal already has "duck typing", when you write

Code: [Select]

writeln(cnt - 1);
writeln(sizeof(cnt - 1)); you notice which type it chooses.

That is a major advantage of Pascal compared to C that you can have overloaded functions with different types and then FPC chooses a type on its own. In C, you could not have a writeln function because you always have to give it a type yourself.

and it was an advantage of Pascal that you can omit the type of constants. const x = 12.34;
In C, you would have to specify the type, like const float x = 12.34;

Sure, if the "cnt" function was cardinal to start with, codetools would create a loop counter of type cardinal => but at least that would be declared on the variable.

codetools actually does that

but FreePascal is smarter than Lazarus

[Martin_fr]

But then to use duck typing as argument, we first need to agree its a good idea (which I fiercely oppose). One of the really really major points for Pascal is that it is (very much mostly) strong typed. Do not destroy that.

Just one example (after that I will not reply to duck typing in this thread). Make the change

Code: Pascal  [Select][+][-]

1. program Project1;{$mode objfpc} {$R-}{$Q-}
2. type
3.   TNum = integer;
4.   //TNum = cardinal;
5.  
6. function cnt: TNum; begin Result := 0; end;
7.  
8. //var i: TNum;
9. var i: integer;
10. begin
11.   for i := 0 to cnt - 1 do writeln(i);
12.   readln;
13. end.
14.  

So long as "i: integer" it works fine. I can change the type of "cnt".
If i follows that type, and it becomes cardinal, then the loop will do a lot of work.

In this case, the problem is again "var i: TNum;"

It should work fine with "var i := cnt - 1"

How? How, then should it work?

Now if "cnt" is cardinal, then so must the loop variable be.
So we would get the same effect.
 
Well, ok on a 64 bit system / not sure about 32 bit), the expression is calculated using temporary int64 values.
On 32 bit systems loop counters can not be 64 bits => so boom.

But even then, there are 2 numbers (from and to)

Code: Pascal  [Select][+][-]

1. for var i := f_qword() to f_int64() do ;

which one should it choose?

And also if "cnt(): qword" => I am not sure if the expression still uses int64 or if it then silently changes to qword (in which case: boom)



And, yes, if you have fixed types (as it is now), then you still must check if they are well chosen for the values that the code can work with. But making sure your code is correct is kind of expected.

With duck typing, you seem to say "it takes away the need for that check", but I say "It takes a way the possibility of this check".
Of course, unless I know every decision the compiler will make on any circumstance. But if I have to predict that, to make sure my code is correct, then it is way easier to just specify the type hardcoded.

The issue is, we have different integer types because we need them to process different data. Since the data is not part of the code, the compiler does not know the data that will be processed. Therefore the compiler can not 100% correctly predict types. As a human I should know what I indent my code to deal with.

[Martin_fr]

Off course the better example comes to mind when I posted.

Code: Pascal  [Select][+][-]

1.    function cnt: integer {cardinal} begin Result := 0; end;
2.      
3.     begin
4.       for var i := 0 to cnt - 1 do begin
5.          {...}
6.          bar(i);
7.          {...}
8.       end;
9.     end.
10.      

Now, ok, so lets say we get away with the compiler making i: int64 (and its 64 bits)....

"function bar" has different overloads for integer and int64. They do the same / get the same result. But the 64 bit overload is a huge lot slower.

So when at some point after (days/weeks) you changed "cnt" to cardinal, and withat made "i: int64" you eventually use the part of the app that enters that loop...
Good luck finding why it suddenly is that slow.

[PascalDragon]

FreePascal already has "duck typing", when you write

Code: [Select]

writeln(cnt - 1);
writeln(sizeof(cnt - 1)); you notice which type it chooses.

That is a major advantage of Pascal compared to C that you can have overloaded functions with different types and then FPC chooses a type on its own.

WriteLn is a bad example considering that it's a compiler intrinsic and does not follow the usual overloading mechanisms.
Also by the way, just move from C to C++ and you have overloading and with modern C++ one could indeed create a function like WriteLn (except for the length modifiers with :).

[BeniBela]

How? How, then should it work?

Now if "cnt" is cardinal, then so must the loop variable be.
So we would get the same effect.
 
Well, ok on a 64 bit system / not sure about 32 bit), the expression is calculated using temporary int64 values.

this will be 64 bit

On 32 bit systems loop counters can not be 64 bits => so boom.

maybe it won't compile at all there

But even then, there are 2 numbers (from and to)

Code: Pascal  [Select][+][-]

1. for var i := f_qword() to f_int64() do ;

which one should it choose?

f_qword() - f_int64()  is int64, then that would probably be int64

The issue is, we have different integer types because we need them to process different data. Since the data is not part of the code, the compiler does not know the data that will be processed. Therefore the compiler can not 100% correctly predict types. As a human I should know what I indent my code to deal with.

usually SizeInt everywhere works. at least on a 64-bit system

So when at some point after (days/weeks) you changed "cnt" to cardinal, and withat made "i: int64" you eventually use the part of the app that enters that loop...
Good luck finding why it suddenly is that slow.

a profiler would show it

WriteLn is a bad example considering that it's a compiler intrinsic and does not follow the usual overloading mechanisms.

var x := ... might need to work like an compiler intrinsic

Also by the way, just move from C to C++ and you have overloading and with modern C++ one could indeed create a function like WriteLn (except for the length modifiers with :).

C++   compiles too slowly. then I would have to buy a new computer

[Martin_fr]

a profiler would show it

Yes, there is a tool to find any bug... But finding it still takes time. And if a user reports it on a release, it may take extra time to even find a way to reproduce...
The entire point is, it just adds one (or several) more point of failure.

It isn't a question if it can technically be done (and work in some cases). That applies to a big lot of things. It is a question if adds more gain than pain. (see next section)


Btw, I have myself experienced that pain. I have done work in languages that don't have strong types (JS, Perl). At one time it was so bad, I added a framework of my own that allowed to check for type correctness.  (And given that we now have typescript / and someone said Python has some type stuff too, I am obviously not alone, and if people from those languages want types, well that says a lot).

Mind you, I am absolutely fine with duck typing for small scripts, usually throw away after usage. So yes, if all I need is to write code to solve something just once, and then never have to maintain that code (and it never grows big) => duck typing is a cool thing.
But it seems to me that is not the usual use case for Pascal. And the moment you have to maintain code over time => duck typing becomes a major pain (as I said, I have been there, so I do know to well what I am talking about)