International Pascal Congress 2023

[Bogen85]

It is only possible in very recent versions of Delphi. I hope it does not make it into FPC.

It does not need to ever make it into FPC.

The same thing can already be achieved in FPC.

Yeah, introducing a new procedure is one way. But I want to limit the scope to a block. That's why I emphasized _block_ in my OP.

Using a procedure means, it's going to reserve a whole new context on the stack, eh? I don't want this.

So there's the inline modifier copying the procedure's body to the place where it's called. Huh. Uhm. That's a sub-optimal solution: Normally you'd introduce procedures if they're either called multiple times or they serve a well-defined task. This is not necessarily the case.

No!@@! I explained that by declaring the procedure *inline* you achieve *block* scoping, as can be seen from the assembler output. If it is just the eye candy of just *declaring* a variable in block scope? That doesn't add any value regarding generated code efficiency and there are plugins available for *editors* that can do just that for Delphi. I am not sure about Lazarus, but I won't be surprised if it is available.  The advantage over C's lazy typing is that in Pascal a separate procedure leads to easier to maintain sourcecode. Which is, btw, of course also possible in modern C.
There is no obvious reason to add bad coding habits to Pascal, imnsho.

As you have pointed out several times in other posts.

Once I saw all your replies on the issue and put it in practice in my own code, I saw no reason for that to come to FPC.

[Joanna]

Inline variable declarations is a horrible idea I’m glad it wasn’t implemented.

[silvestre]

The organization of a congress for Pascal should receive our support, it is very good news. If I had to discuss language issues with other people, for example I would add:

I like very much Object Pascal, and sometimes .....

1.-I have wondered why we can't have in pascal a "step" statement inside the [for-to] that allows us to jump the index in a direct and clean way, to the well-known 1+1?.

2.-Also why the [ Case of ] statement, does not facilitate us to work with variables as a string, or other useful types.... I believe that this would help to write an easier and cleaner code in many cases of programming.

I am aware of the direct rejection of inline variables and I agree with most of the objections. But it would be unwise to declare a temporary index to traverse [for-to] blocks. If a variable is meant to be used only once, why declare it in a global section of a function or procedure and not do it locally (inline)?

Inline variable declarations is a horrible idea I’m glad it wasn’t implemented.

[domasz]

1.-I have wondered why we can't have in pascal a "step" statement inside the [for-to] that allows us to jump the index in a direct and clean way, to the well-known 1+1?.

That would be sweet!
I'd also love a foreach loop, something like:
foreach (array as i=>elem) do

[440bx]

1.-I have wondered why we can't have in pascal a "step" statement inside the [for-to] that allows us to jump the index in a direct and clean way, to the well-known 1+1?.

It would be nice but, personally, it's really very rare that I need it.   IOW, I don't miss it.

2.-Also why the [ Case of ] statement, does not facilitate us to work with variables as a string, or other useful types.... I believe that this would help to write an easier and cleaner code in many cases of programming.

A "case" statement that not only accepts variables but, accepts _multiple_ variables, IOW, a multi-variate table.  It's amazing how much cleaner some code gets when a facility like that is available.  COBOL85 has it (it's called "evaluate") but, for a significant percentage of programmers, the fact that the feature is present in COBOL is enough to put it down with "disdain".  That's very unfortunate.

But it would be unwise to declare a temporary index to traverse [for-to] blocks. If a variable is meant to be used only once, why declare it in a global section of a function or procedure and not do it locally (inline)?

That's a valid point.  The real, solid solution that is perfectly in line with Pascal's spirit is to have local/inline _scopes_.  An inline scope is like a function/procedure that is not callable but, has its own local constants, type and var sections along with its code.  If I recall correctly, ADA implements local scopes, a great feature to keep code clean and easy to maintain.

The real problem with Pascal is that there isn't a group of language experts analyzing the language non-stop and creating a new standard every few years.  Instead, whatever someone thinks is a good idea (which may or may not be the case) and has some influence in the development of a compiler is a close to deciding factor for it to be implemented.  With that as "methodology", the result is usually a "mixed bag" with inconsistencies in many corners.

[Joanna]

Silvestre
To answer some of your questions yes you can increment variables in pascal using the while .. do or repeat .. until loops you can have a numerical variable in there and do something like inc (x,3);

Actually you could implement skipping behavior in a for loop using continue
Like to inc loop by 4 have something like

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

1.  For x:= 4 to 100 do
2.        if (x mod 4) = 0
3.            Then {code}
4. or
5. For x:= 4 to 100 do
6.       Begin
7.       If (x mod 4 ) > 0 Then continue;
8.        {Code}
9.        End;

Stepping the index in a for loop is not a good idea because it could go past the range of values that the index was intended to have.

You can use string type Variable in case statement I do it with Lazarus. You can also use enumerated data types and chars in case statements.

A variable only used once doesn’t seem like a good reason to break the conventions of pascal. Just declare variables needed in the var section no need for inline.

I'd also love a foreach loop

I once saw a for each in turbo pascal using tcollection.

There are other ways to iterate through things besides loops you can iterate through sets ...for ch in charset do etc

[marcov]

Not Lazarus, but FPC or the language: inline variable declarations. *shudders*

I didn't know this was possible! It might be very useful when porting code from C-based languages but I strongly believe such code should only be possible in a special "compatibility"mode, eg. {$MODE C} and not part of regular code base.

Since it is fairly trivial to fix (it doesn't change the logic of the program to move it to the VAR), I don't think it would do anything to improve porting.

Also, it causes a slippery slope where new features are used for non-porting related purposes, and one-by-one all kinds of combination-of-features and corner case bugs get reported. We saw that with C operators. Not again, not for near zero gain.

But the Delphi case is special in the sense that even though it is for bad reasons (mostly trying to be "modern" in the hope of getting some traction in their mobile development efforts), it IS now part of the current Delphi dialect, and when more and more code starts (ab)using it, we may have to comply. (maybe with some nag warnings that the feature is only for compatibility purposes and not recommended).

The past 5-10 years, the Delphi world is increasingly divided between the upgraders (having subscription and being on the latest and greatest), and the non upgrades that are on old ansistring versions from D7..D2007, quite often working in factory automation. I work for a company in between, we use Delphi Seattle (DX10.0), (one of ?) the last versions before mandatory subscription.

[sketch]

1.-I have wondered why we can't have in pascal a "step" statement inside the [for-to] that allows us to jump the index in a direct and clean way, to the well-known 1+1?.

Do you mean something similar to this in NetRexx?

Code: [Select]

loop i = 1 to 10 by 2
  say i
end
which returns:

Code: [Select]

1
3
5
7
9


[silvestre]

Hi Skecth,

Exactly, your example through NetRexx shows simplicity and clarity, the same is offered by other dialects.

1.-I have wondered why we can't have in pascal a "step" statement inside the [for-to] that allows us to jump the index in a direct and clean way, to the well-known 1+1?.


Do you mean something similar to this in NetRexx?

Code: [Select]

loop i = 1 to 10 by 2
  say i
end


Hi Joanna,

Regarding the strings, you are right for freepascal, a step forward compared to Delphi. 

Silvestre
You can use string type Variable in case statement I do it with Lazarus. You can also use enumerated data types and chars in case statements.

[Fred vS]

1.-I have wondered why we can't have in pascal a "step" statement inside the [for-to] that allows us to jump the index in a direct and clean way, to the well-known 1+1?.

Do you mean something similar to this in NetRexx?

Code: [Select]

loop i = 1 to 10 by 2
  say i
end

which returns:

Code: [Select]

1
3
5
7
9


You may use inc(i,y), like Joanna proposed:

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

1. i := 1;
2. while i < 10 do
3. begin
4. writeln(i);
5. inc(i,2);
6. end;

[PascalDragon]

Not Lazarus, but FPC or the language: inline variable declarations. *shudders*

I didn't know this was possible! It might be very useful when porting code from C-based languages but I strongly believe such code should only be possible in a special "compatibility"mode, eg. {$MODE C} and not part of regular code base.

No. Something like that will not be added. This is a Pascal compiler, not a C compiler.

1.-I have wondered why we can't have in pascal a "step" statement inside the [for-to] that allows us to jump the index in a direct and clean way, to the well-known 1+1?.

There exists a bugreport with a patch for that, though that patch doesn't apply to current main.

2.-Also why the [ Case of ] statement, does not facilitate us to work with variables as a string, or other useful types.... I believe that this would help to write an easier and cleaner code in many cases of programming.

The case-statement in FPC already supports strings as an expression. And there is a bug report with a merge request to support it for class types. Other types don't really make sense and performance wise they also don't improve anything.

I am aware of the direct rejection of inline variables and I agree with most of the objections. But it would be unwise to declare a temporary index to traverse [for-to] blocks. If a variable is meant to be used only once, why declare it in a global section of a function or procedure and not do it locally (inline)?

Yes, it would be unwise. It's already bad enough that the on-clause of except-handlers has that.

The real problem with Pascal is that there isn't a group of language experts analyzing the language non-stop and creating a new standard every few years.  Instead, whatever someone thinks is a good idea (which may or may not be the case) and has some influence in the development of a compiler is a close to deciding factor for it to be implemented.  With that as "methodology", the result is usually a "mixed bag" with inconsistencies in many corners.

One of the reasons we're hesitant to add simply add everything and the kitchen sink.

I'd also love a foreach loop, something like:
foreach (array as i=>elem) do

As long as you don't need an index you can already do for elem in array.

Stepping the index in a for loop is not a good idea because it could go past the range of values that the index was intended to have.

It wouldn't be a problem, because with the regular for-loop as well the loop ends once the index is one past the to or downto value. And the patch I mentioned above handles that correctly.

[Joanna]

I’m glad to hear that the developers of fpc are reluctant to try to imitate every trend in other popular programming languages that comes along.

It’s best to stick to your principles and do what is best for fpc even if it means deviating from Delphi I think.

I once watched my favorite online game be slowly destroyed because the makers of the game started adding features of competitors. As a result they got rid of all the people who liked the game as it was and did not succeed in luring customers away from the competitors.

People who like other languages better than pascal are not going switch to fpc even if all the features from their favorite language were somehow added.

That being said it certainly doesn’t hurt to monitor the developments in other languages and implement things that don’t clash with the fundamental design of pascal. One example of this is the // comment

[dbannon]

......
The same thing can already be achieved in FPC.

....... I explained that by declaring the procedure *inline* you achieve *block* scoping, as can be seen from the assembler output. If it is just the eye candy of just *declaring* a variable in block scope? ....

Just in case someone else is looking for that discussion, its at https://forum.lazarus.freepascal.org/index.php/topic,29604.0.html

It works but is quite 'wordy'.

Davo

[Bogen85]

Just in case someone else is looking for that discussion, its at https://forum.lazarus.freepascal.org/index.php/topic,29604.0.html

It works but is quite 'wordy'.

Davo

Wordy, maybe. But when inline vars are allowed anywhere it can get very cluttered.
You can lose track of all the variables in the scope if the function gets too long.

So while it might be wordy, I'd also consider it more tidy.

So wordy and tidy vs brief and messy...

Yes with discipline you can avoid being messy, but with pascal you have no choice but to make your scopes very obvious.

It also helps in keeping your code factored.

So I see it more as a plus than a minus. (the wordiness).

Pascal is already is lot more wordy than many other mainstream languages, so I don't see it as real issue, once you are already use to it.

[ccrause]

Something I miss is a Pascal language philosophy. New features should be tested against this philosophy to check if it enhance the language, or change its nature. For instance does Pascal strictly separate definition and implementation/use? This should then help for example in deciding whether inline declared variables fit in or not.