Frankenstein Pascal

[PierceNg]

In the german language there is a Proverb for something like that: "Verschlimmbessern" (I have no idea how to translate that into english

The Internet English translation of that word is "improveworsement". 

[440bx]

If I recall, the situation under consideration was of the following variety:

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

1. var
2.   Variable1, Variable2, Variable3: integer = 0;
3.  

and/or

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

1. begin
2.   ...
3.   Variable1, Variable2, Variable3 := 10;   // All identical types
4.   ...
5. end;
6.  

Yes, I would like to see the FIRST one implemented.  I don't care for the second one because, in that case, MarkMLI's point that they must all be of the same type, which is not guaranteed in the code part, comes into play (in addition to that, I don't recall needing something like that much.)

[ASBzone]

Yes, I would like to see the FIRST one implemented.

Likewise.

[AlanTheBeast]

Likewise.

Likewise^2

I'd even go as far as a "clearlocal" pragma that gens the code to clear all local vars to 0, or an instruction ClearLocalVars;

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

1. Procedure HappyPlace;
2. var
3.       x, y: real;
4.       i, j: word;
5. {$CLEARLOCAL}
6. begin
7.  

or

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

1. Procedure HappyPlace;
2. var
3.       x, y: real;
4.       i, j: word;
5. begin
6.        ClearLocalVars;
7.  

[Fred vS]

As I type this, I'm thinking about the language extension that would allow it to initialize a variable group instead of restricting initialization to a single variable.   Really simple extension too (except if the original compiler code was ill-conceived leading its implementation to be complicated/hard.)

Although in fairness that gets hairy if the assignands aren't all of identical type.

MarkMLl

If I recall, the situation under consideration was of the following variety:

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

1. var
2.   Variable1, Variable2, Variable3: integer = 0;
3.  

and/or

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

1. begin
2.   ...
3.   Variable1, Variable2, Variable3 := 10;   // All identical types
4.   ...
5. end;
6.  

Something like this ?

Fre;D

[440bx]

Something like this ?

Fre;D

That's it.  I didn't know you had already suggested that improvement to the language.

7 years ago, the suggestion had strong opposition. When I made it, it only received some mild opposition.  At this rate, there is hope, maybe in another 7 or 14 years it might make it into FPC.   If anyone needed a reason to live long and prosper, there is one now!. 

[Fred vS]

Something like this ?

Fre;D

That's it.  I didn't know you had already suggested that improvement to the language.

7 years ago, the suggestion had strong opposition. When I made it, it only received some mild opposition.  At this rate, there is hope, maybe in another 7 or 14 years it might make it into FPC.   If anyone needed a reason to live long and prosper, there is one now!. 

Yes, maybe teenage suggestions are too young.

Fre;D

[Seenkao]

In the german language there is a Proverb for something like that: "Verschlimmbessern" (I have no idea how to translate that into english

The Internet English translation of that word is "improveworsement". 

Это означает ухудшить.
Eng: It means to worsen.

---------------------------------------------------------------------------
Извиняюсь, изначально не читал с чего всё началось.

Не стоит многое изменять во FreePascal.
Первоначальная причина: это язык достаточно прост для изучения и позволяет не наделать ошибок новичкам.
Вторая причина: далеко не все "улучшения" - это улучшение!!! Каждый раз, когда что-то хотят внести новое - надо десять раз подумать и решать ("семь раз отмерь, один раз отрежь").

Не стоит ровняться на другие ЯП! От слова "совсем"! Не всё, что есть в других языках - хорошо!

Язык паскаль, достаточно хорошо читается начинающим программировать, а впоследствии, уже становится не так важно, как это выглядит. Скобки это или begin/end.

Да, в некоторых случаях очень удобно одновременно объявить переменные и задать им данные.
Удобно взять и "множеству" переменных присвоить одно значение.

Но! Давайте посмотрим на это со стороны программирования! Каждый, кто так будет делать, со временем не будет понимать, что происходит в программе. Будет забывать как это должно происходить в коде и будет пользоваться "тем, что легче". Как итог, как программист такой человек будет деградировать. А код, создаваемый такими людьми, будет расти.

Я ориентируюсь на основную массу людей, что сейчас идут в программисты. Лично я считаю, что большую часть надо сразу отсеивать и отправлять пользоваться конструкторами. И когда человек уже сам захочет углубиться в программирование, то "милости просим".

google translate:
I apologize, initially I did not read how it all started.

Don't change a lot in FreePascal.
The original reason: This language is easy enough to learn and avoids making mistakes for beginners.
The second reason: not all "improvements" are improvements !!! Every time they want to introduce something new - you have to think and decide ten times ("measure seven times, cut once").

Do not be equal to other programming languages! From the word "absolutely"! Not everything in other languages ​​is good!

The Pascal language is readable enough for beginners to program, and later, it becomes not so important as it looks. The parentheses are either begin/end.

Yes, in some cases it is very convenient to simultaneously declare variables and set data to them.
It is convenient to take and assign one value to a "set" of variables.

But! Let's look at this from the programming side! Anyone who does this will eventually not understand what is happening in the program. He will forget how it should be done in the code and will use "what is easier". As a result, as a programmer such a person will degrade. And the code these people write will grow.

I am guided by the bulk of people who are now going to be programmers. Personally, I think that most of it should be immediately sifted out and sent to use the constructors. And when a person himself wants to delve into programming, then "you are welcome."

[MarkMLl]

Don't change a lot in FreePascal.
The original reason: This language is easy enough to learn and avoids making mistakes for beginners.
The second reason: not all "improvements" are improvements !!! Every time they want to introduce something new - you have to think and decide ten times ("measure seven times, cut once").

Broadly agreed. In particular don't relax type automatic conversion any further: if anything tighten it.

MarkMLl

[PascalDragon]

Next time, please either link the message or quote it. So for the sake of completeness:
And now, where does my statement contradict the one by ASBzone? Please note that my statement explicitly targeted drastic changes like curved brackets instead of begin … end for blocks. Only because we reject such requests for changes does not mean that we'll reject all changes. It definitely depends on what the topic is.

My apologies for not quoting. OK, I note what you're saying about changes which break backwards compatibility such as the use of braces and that you're /potentially/ open to things that don't. But I'd suggest that that's a clarification of what you said earlier, your unqualified "changes" would normally also be read to include non-breaking additions (more C-type operators etc.).

C-operators are a bad example, cause essentially all core devs consider them a bad idea nowadays.

And as far as breaking changes go the cavalier way that the developers broke FileExists() in 3.2.0 severely dented my confidence. If there were a better hole I'd go to it.

With the extension for the support to follow symbolic links or not (which was due to Delphi compatibility) it was decided to make the behaviour consistent across platforms.

While I don't support the idea of locally scoped variables for e.g. for the scope of the variable would not be a problem, because a for-statement is followed always by a single statement (which again can be a block), thus the scope of the variable would be well defined. Same for the with-statement which is followed by a single statement.

I specifically said that it wasn't neatly delimited by the syntax, everybody knows how the semantics work out. In C/C++ you can do

Now you're mixing things. From my perspective you were talking about things like the index variable of the for-loop or the captured expression of the with-statement. These have well defined scopes. For "ordinary" inline variables I agree however that the scoping rules of Pascal are not well defined for that (I wonder how Delphi handles them...). But we have a moratorium on the topic of inline variables anyway...

First of the introduction of helper types was due to Delphi. Second this doesn't change the language, it extends it. A change is something that leads to existing code no longer compiling or working while an extension (ideally) does not affect existing code.

OK, so it's Delphi that's courting popular favour by pretending that it's JavaScript :-) But is it really still sufficiently influential that it's worth emulating?

It's not JavaScript. Delphi introduced that syntax with Delphi.NET as the Delphi equivalent of extension methods which are in my opinion much less well declared than Delphi's helper types are (taken from here):

Code: C#  [Select][+][-]

1. public static class MyExtensions
2. {
3.     public static int WordCount(this String str)
4.     {
5.         return str.Split(new char[] { ' ', '.', '?' },
6.                          StringSplitOptions.RemoveEmptyEntries).Length;
7.     }
8. }

This will allow code like this:

Code: C#  [Select][+][-]

1. string s = "Hello Extension Methods";
2. int i = s.WordCount();

While the usage is the same in Delphi/FPC the declaration is in my opinion much better:

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

1. type
2.   TMyExtensions = type helper for String
3.   private
4.     function GetWordCount: SizeInt;
5.   public
6.     property WordCount: SizeInt read GetWordCount;
7.   end;

Class and record helpers were originally implemented by me (one of my first contributions to the compiler) and they were explicitly added due to Delphi compatibility. Since then however we have embraced them more by introducing the explicit type helper that can be used for classes, records, primitive types and nowadays even interfaces (what Delphi does not support) and I still plan to extend (pun intended) them to essentially all types. And there's also the MultiHelpers modeswitch that got introduced around two years ago that allows multiple helpers for the same type to be in scope without having them inherit from each other (which was by the way a language extension by a third party developer!).

Quick question if I may at this point: either you or another of the core developers described class helpers as being a nasty hack that they wished would go away. While I agree that they're nasty from the POV of object accessibility etc. they're undeniably useful: does the core team similarly feel that type helpers are hackish?

I don't know who said that. As I said however we have embraced them now with default helpers being available in the SysUtils unit and extensions like MultiHelpers.

Only because we reject such requests for changes does not mean that we'll reject all changes.

That may be true but, so far, the impression is that any user suggestion will be rejected as a matter of course.  As I type this, I'm thinking about the language extension that would allow it to initialize a variable group instead of restricting initialization to a single variable.   Really simple extension too (except if the original compiler code was ill-conceived leading its implementation to be complicated/hard.)

See above example: the support for multiple helpers was done by a third party developer and they are currently also working on implicit specialization of generic routines (mainly bottlenecked by me reviewing it, though to be fair, that's also for Delphi compatibility) and they also kicked off a very interesting discussion about a trait-like extension on fpc-pascal. So saying that we're not allowing any extensions in is wrong.

Don't change a lot in FreePascal.
The original reason: This language is easy enough to learn and avoids making mistakes for beginners.
The second reason: not all "improvements" are improvements !!! Every time they want to introduce something new - you have to think and decide ten times ("measure seven times, cut once").

And this second reason is exactly why we're relatively strict with language extensions. We don't add everything and the kitchen sink just because someone says "it's good" even if it just a minuscle thing like 440bx's suggestion of multiple initializations (though I really should reread that thread...).

[ASBzone]

Don't change a lot in FreePascal.
The original reason: This language is easy enough to learn and avoids making mistakes for beginners.
The second reason: not all "improvements" are improvements !!! Every time they want to introduce something new - you have to think and decide ten times ("measure seven times, cut once").

And this second reason is exactly why we're relatively strict with language extensions. We don't add everything and the kitchen sink just because someone says "it's good" even if it just a minuscle thing like 440bx's suggestion of multiple initializations (though I really should reread that thread...).

That is my general stance as well.   But, I also happen to like the multi-initialization suggestion, so I would be encouraged if you would, in fact, find an opportunity to re-read that thread.   

I'm also quite aware that I don't have the time or necessarily the capabilities to make those changes myself, or I would make a patch myself and offer it to review/acceptance.

[MarkMLl]

The language is designed for readability.  Curly braces in C is a disaster.

My Superhero proposal (a few years ago) was to adopt the Ada style simple index variables not needing to be declared.  Its scope would last for the statement and block in which it appears thence to not exist out of the statement block.  Thus:

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

1.  
2.       //.   i not in existence
3.  
4.       for i := 1 to 7 do         // i exists - probably only in a register.
5.             begin                   // no { here  :D
6.                 somestuff;
7.                 aproc(arr[i]);
8.                 x := y * acoolfunction(i);
9.                 writeln (i:4, x:12:3)
10.            end;
11.  
12.       //.   i not in existence
13.  
14.  

This was met with varying degrees of resistance, hostility and derision, alas.

That proposal is all very well if the limits are- as in your example- literal constants. It's much less attractive if they're computed.

I've never tried it, but I suspect that you could in principle write complex programs where every  for  clause and every array declaration operated on an explicit subrange type. Now in that case you could obviously write something like for i in TSomething do without an explicit declaration while still retaining range checking.

MarkMLl

[AlanTheBeast]

That proposal is all very well if the limits are- as in your example- literal constants. It's much less attractive if they're computed.

I've never tried it, but I suspect that you could in principle write complex programs where every  for  clause and every array declaration operated on an explicit subrange type. Now in that case you could obviously write something like for i in TSomething do without an explicit declaration while still retaining range checking.

At the time I might not have presented it clearly enough.  When asked if it should allow enumerated types, I replied "why not?" and things devolved quickly.  (Never mind general snarkiness). 

I just reviewed the enumerated type declaration and see that one can have the ord value of the first member initialized to an arbitrary value (and the rest follow of course...).  Was that in original Pascal?  I don't recall it being so..

But in the end, yes, I believe if such were to be adapted it should be for that dirt simple case of needing a simple index variable and only for such.  That preserves readability and interpretation and isn't a huge stretch on compiler design (IMO).   Not sure if I would go to enumerated types / subranges of same; as the absence of the declaration (near the action - in the proc/func) for the reader would be confusing or at least frustrating.

But as I presented it recently it seems to be clear enough for all.

[MarkMLl]

I just reviewed the enumerated type declaration and see that one can have the ord value of the first member initialized to an arbitrary value (and the rest follow of course...).  Was that in original Pascal?  I don't recall it being so..

Don't believe so, but there's potential pain in the area: there's no real mechanism for extending an enumeration if- as an example- it represents additional operations or statuses in a subclass. Note that I'm not necessarily saying there ought to be, I'm just "tellin' it as it is".

MarkMLl

[trev]

And as far as breaking changes go the cavalier way that the developers broke FileExists() in 3.2.0 severely dented my confidence. If there were a better hole I'd go to it.

With the extension for the support to follow symbolic links or not (which was due to Delphi compatibility) it was decided to make the behaviour consistent across platforms.

Unfortunately the end result is that it broke a lot of code (including in Lazarus). And as for consistency, how do you rename a directory? Of course, you use renameFile() ! How's that for consistency? Especially when the justification provided was:

FileExists on Unix-based systems
Reason for change: Directories are not files, thus it was illogical for FileExists to return True for existing directories. Also this brings it in line with Windows and Delphi.

Directories are not files on UNIX /UNIX-like systems? Really? But they are when they need renaming? Talk about consistency.