FPC Feature request/suggestion

[Leledumbo]

If I would ever allow multiple variable initialization of the same type, I would use Lua multiple assignment as my reference. So the syntax would be:

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

1. var
2.   AInteger,BInteger: Integer = 0,0;
3.  

[440bx]

If I would ever allow multiple variable initialization of the same type, I would use Lua multiple assignment as my reference. So the syntax would be:

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

1. var
2.   AInteger,BInteger: Integer = 0,0;
3.  

Honestly, that is something I definitely would _not_ want.  The reason is, the programmer has to mentally match ... first variable to first initialization... second variable to second initialization... etc.   All the same or nothing.  Avoids confusion.

[jamie]

I the C world this works great! 

 It loads a register with the value once and then defines the variables with multiple moves of that single reloaded register..

 This gives the compiler the chance to optimize code. Otherwise what you see is a complete duplicated process of moving a value into each one..

 Using this syntax not only aids the compiler in optimizing it also helps the coder in initializing , especially if the identifiers are long and many..

 Also, since this aids the compiler and these types fit on the stack most of the time, the compiler to determine the size of the clump and being they are ordered on the stack could also perform a REP. STRING operation....

 There are lots that can be done, and that is the point, does anyone want to bother putting in the time ?

[PascalDragon]

I the C world this works great! 

 It loads a register with the value once and then defines the variables with multiple moves of that single reloaded register..

 This gives the compiler the chance to optimize code. Otherwise what you see is a complete duplicated process of moving a value into each one..

 Using this syntax not only aids the compiler in optimizing it also helps the coder in initializing , especially if the identifiers are long and many..

 Also, since this aids the compiler and these types fit on the stack most of the time, the compiler to determine the size of the clump and being they are ordered on the stack could also perform a REP. STRING operation....

 There are lots that can be done, and that is the point, does anyone want to bother putting in the time ?

That is totally independant of the syntax. FPC could do this as well. In fact if you initialize variables in code instead of in the var section the compiler already is capable to better optimize due to the way how local initialization is implemented compared to in-code initialization (though there is still the possibility to do better).

[munair]

I never thought that this could be such a point of debate. It should be easy for the compiler to implement:

1. collect all identifiers
2. get the type
3. get the initial value (if specified)
4. see if the value matches the type

The only reason I can think of not to implement it is that it breaks Pascal tradition, although that shouldn't be much of a point considering the fact that Pascal also embraced C-style operators.

[MarkMLl]

The only reason I can think of not to implement it is that it breaks Pascal tradition, although that shouldn't be much of a point considering the fact that Pascal also embraced C-style operators.

There are members of the community resolutely opposed to anything C-like. Which is unfortunate, since 40 years on the C-derived languages are beginning to admit the utility of strong type checking, easily used strings and plenty of other things they've traditionally eschewed and spat out.

I seem to recall that @PascalDragon has discussed tuple assignment in the past. Quite frankly, I think that it is no more difficult to keep track of than procedures with optional parameters (which have similar maintenance pitfalls) and would suggest that it's the programmer's responsibility to decide whether to use such things.

Personally, I'd take a leaf from APL's book and mandate that a tuple should either match exactly or that a single element is duplicated. The real problems start when a well-meaning language implementor (who would very likely be working for Microsoft) decides that if the lvalue has ten elements but the tuple on the right only has nine that the final element should be duplicated silently.

MarkMLl

[440bx]

I never thought that this could be such a point of debate. It should be easy for the compiler to implement:

1. collect all identifiers
2. get the type
3. get the initial value (if specified)
4. see if the value matches the type

I share that feeling. 

#1 - the compiler already does it.
#2 - the compiler already does it.
#3 - the compiler already does it (but only if there is one identifier... more on that in a bit)
#4 - the compiler already does it.

All that's left is #3.  That one gives the impression that the compiler is using different productions to parse a single variable definition than it does to parse a variable group.

<...> well-meaning language implementor (who would very likely be working for Microsoft) decides that if the lvalue has ten elements but the tuple on the right only has nine that the final element should be duplicated silently.

sounds like a C programmer...

[flowCRANE]

I have been programming for about 14 years, mainly in different Pascal dialects. Two years in old Pascal (TP7), few years in Delphi (mostly Delphi 7), few years in C/C++ and the last 6 years in Free Pascal.

And I'm still of the opinion that the Pascal syntax (including Free Pascal) is too long and some of the current code constructions too old for this language to be actually pleasant — the syntax should be more condensed and more functional. In addition, some designs are a real abomination, such as variant records — who the hell came up with this? Probably Borland.

The second big problem with this language is the fact that a lot of its users probably remember the American Civil War and are struggling with virtually every suggestion about extending the language's functionality or shortening the syntax, giving some nonsense reasons to reject the offer.

The third problem is the panic fear of structures borrowed from C-style languages, despite the fact that they allow you to significantly shorten the code, without reducing its readability at all. Most developers use such constructions and somehow live. But some could not use this type of construction because probably they would hurt themselves, so don't implement! Like a gardener's dog...

Free Pascal's syntax should be revolutionized so that this language comes out of the shadows and ceases to be perceived by developers around the world as old and useless nowadays. But IMO this is fight the windmills.

As for the main suggestion, I like it — I would like it to be allowed. Assigning one value to many variables at once in one expression too. Assigning multiple values to many multiple variables in Lua-style also.

[Bart]

The second big problem with this language is the fact that a lot of its users probably remember the American Civil War and are struggling with virtually every suggestion about extending the language's functionality or shortening the syntax, giving some nonsense reasons to reject the offer.

There is no need for such offending language.

Bart

[Martin_fr]

giving some nonsense reasons to reject the offer.

Calling your opponents view nonsense. <sarcasm> The greatest of all arguments, that has solved so many disputes before. </sarcasm> (SCNR)

The second big problem with this language is the fact that a lot of its users probably remember the American Civil War

....

But IMO this is fight the windmills.

Well, maybe some of us remember history from the 1860ies.
But, you still remember Don Quixote's fight, which is from around 1605.

[marcov]

I have been programming for about 14 years, mainly in different Pascal dialects. Two years in old Pascal (TP7), few years in Delphi (mostly Delphi 7), few years in C/C++ and the last 6 years in Free Pascal.

Blablabla. But you bring nothing to the table but some sentiment dressed up as how "others" "perceive" the language. And totally steps over why that matters at all.

Frameworks to get something done in a short time is what makes people switch development system, not up to date microsyntax that saves two characters in corner case scenarios. That's for language debate only.

Development system = language+compiler+libraries+ide at the very least.

[flowCRANE]

But you bring nothing to the table but some sentiment dressed up as how "others" "perceive" the language.

Maybe, but we'll see what this thread will do.

In addition, many of the proposals that I think make sense have already been rejected, they have been discussed many times. So why propose them again, since we all know that it will be no different than before? Even the suggestion from this thread AFAIR has already been discussed.

BTW: don't feel attacked — that was not the goal. This is just my opinion, these are my feelings in this topic. We have another suggestion to modify the language and unfortunately the same arguments — no, because the programmer can write illegible code.

[440bx]

I have to admit that I find the one reason given so far to be a bit on the flimsy side.  Here is why: when declaring multiple variables in a group, the _one_ and only _one_ data type specified applies to all the variables in the group.  The data type is assigned to each identifier.  If there was a value specified then, that value can be assigned to each identifier just as the data type is.

Plus, it really is inconsistent that one variable can be initialized but not a variable group.

Just for consistency and symmetry, the compiler should allow initializing a group of variables by specifying a single value, just as it allows specifying their data type with a single data type "value".

I think the chance of the value getting lost is the same as the data type getting lost. 

Maybe, but we'll see what this thread will do.

It's not very likely to make any difference.  It would be nice if it did.

As I stated before, I would be against the Lua way of multiple initial values because it's too easy to flip values and end up with the wrong initial values for some variables.   The few seconds it saves in typing will be lost many times over debugging just to find a transposition.  Good features have little room for error, bad ones have a lot of room for errors such as "=" instead of "==" and a plethora of those in the C language.

[flowCRANE]

As I stated before, I would be against the Lua way of multiple initial values because it's too easy to flip values and end up with the wrong initial values for some variables. […]

Nothing will stop people from making mistakes, especially if someone is not focused when writing the code or if they lack knowledge, so refraining from expanding the functionality of the language is not a solution to the problem.

I can make a lot of mistakes when writing code, so the program won't work properly (unexpected crashes, exceptions, memory leaks and many more), but it's my fault as a careless or uneducated programmer, not the language itself.

Free Pascal is a great language and it can be even better. But the need for change, which many people will never agree.

[winni]

@furious programming

If you want to have "a little bit of everything" than Pascal is not the right language for you .

The bash would probably be better.
There is everthing inside:
C , Basic, Java, Pascal, RegEx ....

And if you think that the syntax of Pascal is too oldfashioned:

Make an ElectroPop-Amphetamin Library with all your new syntax.

Winni