FPC Feature request/suggestion

[munair]

There is no need for a combined ":=" and "==" if the language is well designed. In 6 years of frequent Pascal programming I still find myself forgetting the colon with assignment statements.

If assignment "=" is combined with comparison like "==" and no assignment is allowed in an expression then there can be no mistake.

Both Pascal and C suffer from inconsistencies and bad design, although IMO Pascal's design overall is probably better.

A good example is loop constructs, which in various languages often lead to misunderstanding and/or confusion because of different keywords for different constructs. Pascal and C both suffer from this.

In Pascal emphasis lies on BEGIN..END except with REPEAT..UNTIL, which forms a unique block by itself, whereas WHILE has a different construct altogether, even though both are supposed to be complementary.

C's solution is even worse having the condition outside of the block delimiters:

Code: Text  [Select][+][-]

1. do {
2.   statements
3. } while (expression);

Go decided to do away with different constructs altogether and only uses FOR, which has limits and is unintuitive.

A better solution IMO would be to have one keyword for the variable loop (as opposed to the fixed FOR loop) followed by the usual block delimiters, with either a WHILE condition at the top, or a UNTIL condition at the bottom. Such a construct is not just consistent with the usage of block delimiters but also with statements inside the block that control the loop, such as BREAK and CONTINUE:

Code: Text  [Select][+][-]

1. count = 0;
2. loop do
3.   while count < 10;
4.   // ..
5.   count = count + 1;
6. end;
7.  
8. count = 0;
9. loop do
10.   count = count + 1;
11.   // ..
12.   until count >= 10;
13. end;
14.  

There is a lot to be said about language design and it's a challenge to get it consistent across the board. But I believe it can be done, even if it leads to syntax that requires some getting used to.

Back on topic, SharpBASIC allows various ways to declare a variable:

Code: Text  [Select][+][-]

1. var a: int;
2. var b, c, d: int8 = 0;
3.  
4. var is
5.   e: string;
6.   f: uint16 = 100;
7.   g, h, i, j: real32;
8. end;
9.  

[flowCRANE]

Doesn't have to *stop*. Everybody makes small mistakes and typos all the time.

So stop using the argument that some new language feature is bad, because programmer can do mistake or write unreadable code. Everyone should stop using such arguments, because in the comparison with most popular languages, it looks just silly.

Language design is about minimizing both the rate and damage, and maximizing the detection.

And, at the same time, all Pascal dialects:

• allow to skip the last semicolon in the block of instructions — which can cause different control flow that expected,
• allow skipping round brackets when calling functions — which force the programmer to analyze the code instead of just look at it and know what is going on immediately,
• declaring typed constants that are not constants, because their value can be modified,
• force not to use end to close the case in the variant record — which is just ridiculous, totally opposed to structure of the other blocks,
• probably few (or many) more.

But the C-style languages are poorly designed.

And back to the variant records — they are really ugly freaks, completely unintuitive to use and long ago they should be replaced with legible unions (with keyword union instead of record) whose syntax will not cause a headache.

For instance, C allows assigning within an expression thus, a statement "if (a = b) ... " is correct in spite of the fact that it is extremely likely the programmer meant to type "if (a == b) ...".

But nobody like to have something like this in Pascal.

Every time there is a suggestion to borrow a construction from the C-style language, someone gives as an argument other constructions that have nothing to do with the proposed one, and only serve to show that it is a bad idea. C'mon guys, modeling on other languages is not bad, especially if you choose their best features to improve your own language.

[PascalDragon]

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.

Apparently not. I was directly referring to your request:

it would be nice if the compiler would allow an initial value for multiple variables in the same declaration.

So "collect all identifiers" is not what the compiler already does. Perhaps I should program my wording more carefully? 

FYI: that is exactly what the compiler does. Which is why I wrote that technically it would be no problem at all.

However what escapes many here is that initialization in the var-section is less efficient than initializing in code:

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

1. program tvarinit;
2.  
3. procedure Test;
4. var
5.   SomeVar1: Integer = 0;
6.   SomeVar2: Integer = 0;
7.   SomeVar3: Integer = 0;
8.   SomeVar4: Integer = 0;
9. begin
10.   SomeVar1 := 0;
11.   SomeVar2 := 0;
12.   SomeVar3 := 0;
13.   SomeVar4 := 0;
14.   Writeln(SomeVar1, SomeVar2, SomeVar3, SomeVar4);
15. end;
16.  
17. begin
18.   Test;
19. end.

This will generate (without optimizations) the following code:

Code: ASM  [Select][+][-]

1. # Var SomeVar1 located at rbp-4, size=OS_S16
2. # Var SomeVar2 located at rbp-8, size=OS_S16
3. # Var SomeVar3 located at rbp-12, size=OS_S16
4. # Var SomeVar4 located at rbp-16, size=OS_S16
5. # [4] var
6.         movw    TC_$P$TVARINIT$_$TEST_$$_defaultSomeVar4(%rip),%ax
7.         movw    %ax,-16(%rbp)
8.         movw    TC_$P$TVARINIT$_$TEST_$$_defaultSomeVar3(%rip),%ax
9.         movw    %ax,-12(%rbp)
10.         movw    TC_$P$TVARINIT$_$TEST_$$_defaultSomeVar2(%rip),%ax
11.         movw    %ax,-8(%rbp)
12.         movw    TC_$P$TVARINIT$_$TEST_$$_defaultSomeVar1(%rip),%ax
13.         movw    %ax,-4(%rbp)
14. # [10] SomeVar1 := 0;
15.         movw    $0,-4(%rbp)
16. # [11] SomeVar2 := 0;
17.         movw    $0,-8(%rbp)
18. # [12] SomeVar3 := 0;
19.         movw    $0,-12(%rbp)
20. # [13] SomeVar4 := 0;
21.         movw    $0,-16(%rbp)

As you can see the initializations in the var section are implemented using constants, thus resulting in loads of global variables, while the other is done using simple mov instructions.

With -O4 the code will look like this:

Code: ASM  [Select][+][-]

1. # [10] SomeVar1 := 0;
2.         xorw    %ax,%ax
3. # Var SomeVar2 located in register r12w
4. # [11] SomeVar2 := 0;
5.         xorw    %r12w,%r12w
6. # Var SomeVar3 located in register si
7. # [12] SomeVar3 := 0;
8.         xorw    %si,%si
9. # Var SomeVar4 located in register di
10. # [13] SomeVar4 := 0;
11.         xorw    %di,%di

Which is probably more efficient than using a REP STOSD or something like that.

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

1. 000000010002C991 4889e5                   mov    %rsp,%rbp
2. 000000010002C994 488d6424c0               lea    -0x40(%rsp),%rsp
3. 000000010002C999 48894df0                 mov    %rcx,-0x10(%rbp)
4. 000000010002C99D 488955f8                 mov    %rdx,-0x8(%rbp)
5. unit1.pas:36                              A :=0;B:=0;C:=0;D:=0;E:=0;F:=0;
6. 000000010002C9A1 c745e800000000           movl   $0x0,-0x18(%rbp)
7. 000000010002C9A8 c745e000000000           movl   $0x0,-0x20(%rbp)
8. 000000010002C9AF c745d800000000           movl   $0x0,-0x28(%rbp)
9. 000000010002C9B6 c745d000000000           movl   $0x0,-0x30(%rbp)
10. 000000010002C9BD c745c800000000           movl   $0x0,-0x38(%rbp)
11. 000000010002C9C4 c745c000000000           movl   $0x0,-0x40(%rbp)
12.  

Just an example on how the compiler can do a better job at this..

Did you compile with optimizations?

[MarkMLl]

There is no need for a combined ":=" and "==" if the language is well designed. In 6 years of frequent Pascal programming I still find myself forgetting the colon with assignment statements.

In 40 years of frequent Pascal programming, I say there is a need :-)

In Pascal emphasis lies on BEGIN..END except with REPEAT..UNTIL, which forms a unique block by itself, whereas WHILE has a different construct altogether, even though both are supposed to be complementary.

Most recently-introduced Pascal constructs plus records etc. have explicit termination. It's really only "if", "while" and "with" that are outliers, which is why there's occasional discussion (which I'm sure you've seen) related to the superiority of the Modula-2 syntax which fixed the "dangling else" issue.

MarkMLl

[munair]

As you can see the initializations in the var section are implemented using constants, thus resulting in loads of global variables, while the other is done using simple mov instructions.

The SharpBASIC compiler has a different approach entirely. First it collects the identifier(s). Then it takes the type and finally checks if there is an initialization.

At a later stage, after the declaration block has been processed, variables get 'registered' meaning that asm code is emitted based on the variable's properties. The example of variable declarations I gave in my previous post would emit the following code:

Code: ASM  [Select][+][-]

1. SECTION .data
2.  
3. ; define b
4. _I1                 db 0
5. ; define c
6. _I2                 db 0
7. ; define d
8. _I3                 db 0
9. ; define f
10. _I5                 dw 100
11.  
12. SECTION .bss
13.  
14. ; define a
15. _I0                 resd 1
16. ; define e
17. _I4                 resb 2
18. ; define g
19. _I6                 resd 1
20. ; define h
21. _I7                 resd 1
22. ; define i
23. _I8                 resd 1
24. ; define j
25. _I9                 resd 1

No constants are involved here. Identifiers declared as const would similarly go to SECTION .rodata

For completeness, the same declarations in a procedure (32 bits):

Code: ASM  [Select][+][-]

1. ; define b
2.         mov     eax, 0
3. ; save b
4.         mov     [ebp - 8], al
5. ; define c
6.         mov     eax, 0
7. ; save c
8.         mov     [ebp - 12], al
9. ; define d
10.         mov     eax, 0
11. ; save d
12.         mov     [ebp - 16], al
13. ; define f
14.         mov     eax, 100
15. ; save f
16.         mov     [ebp - 24], ax

The string type is not in here because it has not been fully implemented yet. But as you can see, there are no constants involved. I guess that's what's holding back FP from implementing it.

[Martin_fr]

So stop using the argument that some new language feature is bad, because programmer can do mistake or write unreadable code.

Well that is a question of how to judge the "error factor" (however this is to be defined or determinated).
So hypothetically:
- Every feature does have an "error factor"
- You can get some sort of "error factor" for an entire language
- You can get some sort of "error factor" that the language should have, if previous mistakes were remedied.
Then a desirable goal would be to keep the "error factor" of a new feature lower than the "error factor" that the language should have. So the overall language does not get further away from its target.

Everyone should stop using such arguments, because in the comparison with most popular languages, it looks just silly.

Popularity has little do to with that.
Popularity does not say anything about quality or correctness.

And (as explained by others over the past years on this forum) popularity does not arise because of those features.
Popularity is mostly archived by other properties of those languages or the environment the come with.

This is like judging the popularity of a gym, by the color of there door handles. Sure there might be popular colors for door handles, but that does not majorly contribute to the amount of people joining a specific gym.

Every time there is a suggestion to borrow a construction from the C-style language, someone gives as an argument other constructions that have nothing to do with the proposed one, and only serve to show that it is a bad idea.

True.

[440bx]

Pascal's design overall is probably better.

Yes, just like it's probably better to enjoy an ice cream on a beach in Tahiti than being run over by a truck in a third world country. Yes, indeed, Pascal is "probably" better.

As far as loops and many other flow control constructs, it's very unfortunate that so many programmers make their hobby to bash COBOL because, aside from the fact that it is wordy, the control flow constructs it offers are well thought out and, should be used as a guide (which does not mean carrying over their wordiness.)

Code: Text  [Select][+][-]

1. var a: int;
2. var b, c, d: int8 = 0;
3.  
4. var is
5.   e: string;
6.   f: uint16 = 100;
7.   g, h, i, j: real32;
8. end;
9.  

I like lines 2 and 7.  I like those

And, at the same time, all Pascal dialects:

• allow to skip the last semicolon in the block of instructions — which can cause different control flow that expected,
• allow skipping round brackets when calling functions — which force the programmer to analyze the code instead of just look at it and know what is going on immediately,
• declaring typed constants that are not constants, because their value can be modified,
• force not to use end to close the case in the variant record — which is just ridiculous, totally opposed to structure of the other blocks,
• probably few (or many) more.

But the C-style languages are poorly designed.

No.  You're exaggerating.

Point 1. there is only one case (that I've come across) where the absence of the semicolon could cause execution flow to be different than the expected one and that is because of the use of "else" in a "case" statement.

Point 2. That's right and, it is unfortunate.  Particularly considering that in some cases FPC will make them required thereby creating an inconsistency (in the case it requires them, it doesn't have a choice, it's a damned if you do, damned if you don't.)

Point 3.  That's a Borland-ism.  That would be an embarrassment in any language.  Pascal was _not_ designed that way.

Point 4.  You got a point.  Symmetry went out the window... that's unfortunate.

About the C language... once you take a good look at it, it becomes a bit dubious that it was actually "designed".  That said, it does have some features that are desirable, unfortunately, as most everything in it, the implementation is atrocious and that's when it's good.

For instance, C allows assigning within an expression thus, a statement "if (a = b) ... " is correct in spite of the fact that it is extremely likely the programmer meant to type "if (a == b) ...".

But nobody like to have something like this in Pascal.

I would be completely against that kind of construct in _any_ language.  That's is an invitation to create nasty problems because 2 fingered typists want to save time. 

Every time there is a suggestion to borrow a construction from the C-style language, someone gives as an argument other constructions that have nothing to do with the proposed one, and only serve to show that it is a bad idea. C'mon guys, modeling on other languages is not bad, especially if you choose their best features to improve your own language.

About that, I feel the way you do.  I don't care where a feature is from.  If a good implementation of that feature can result in cleaner and simpler code, I'm all for it, no matter where it comes from, even COBOL, to the dismay of some.


@PascalDragon,

I have to agree with Munair.  Whether the variables are initialized in their declaration or in code should _not_ make a difference since they are initialized with constant values.

[PascalDragon]

The string type is not in here because it has not been fully implemented yet. But as you can see, there are no constants involved. I guess that's what's holding back FP from implementing it.

No. That's not what's holding FPC back. It could just as well reuse the constant. As said, the technical side is not the problem. (And constants are used because that's the same mechanism that's also used for global variables)

I have to agree with Munair.  Whether the variables are initialized in their declaration or in code should _not_ make a difference since they are initialized with constant values.

As said above it makes a difference, because FPC reuses the mechanism that is used to initalize global variables.

[flowCRANE]

Then a desirable goal would be to keep the "error factor" of a new feature lower than the "error factor" that the language should have. So the overall language does not get further away from its target.

Indeed. But because the ”error factor” is a disputable issue (also taking into account individual abilities of the programmers), it is difficult to make an unambiguous assessment. Many say that Pascal is an unsafe language because it doesn't have GC or at least smart pointers, but for me it's nothing unsafe.

Popularity has little do to with that […]

I cannot describe it different — quite poor English, sorry. I did not mean popularity as numbers for TIOBE statistics. Simply put, other languages that are popular are still great and functional, allowing you to write concise and readable code. Despite the fact that maybe they allow you to make more mistakes than in Pascal. And nobody care about that.

No.  You're exaggerating.

I don't think so, but you admit that there is something to it.

Point 1. there is only one case (that I've come across) where the absence of the semicolon could cause execution flow to be different than the expected one and that is because of the use of "else" in a "case" statement.

But this case exists and should not. All or nothing.

Point 2. That's right and, it is unfortunate.

That's why I'm using round brackets everywhere, but many, many developers not. This makes analyzing someone else's code outside the IDE (without hints and jumping/history tools) is difficult.

Point 3.  That's a Borland-ism.  That would be an embarrassment in any language.  Pascal was _not_ designed that way.

And it exists because of backward compatibility. But should not in modern Free Pascal.

Point 4.  You got a point.  Symmetry went out the window... that's unfortunate.

So why we still have no replacement for old school case-style variant records? Nobody want it?

About the C language... once you take a good look at it, it becomes a bit dubious that it was actually "designed".  That said, it does have some features that are desirable, unfortunately, as most everything in it, the implementation is atrocious and that's when it's good.

C is old, dirty and unsafe, but fast and concise. I like it.

[marcov]

Doesn't have to *stop*. Everybody makes small mistakes and typos all the time.

So stop using the argument that some new language feature is bad, because programmer can do mistake or write unreadable code.

I tried to explain to you that such things are not black/white but a matter of chances.

Everyone should stop using such arguments, because in the comparison with most popular languages, it looks just silly.

The most popular syntax being a highlevel assembler designed to operate a seventies telephone switch, and mostly frozen in design 5 years later. And WE get flak for not implementing new stuff?

Why don't you take it to comp.lang.c ? They surely could use your there :-) They LOVE new feature suggestions, and being explained what to do.

[flowCRANE]

The most popular syntax being a highlevel assembler designed to operate a seventies telephone switch, and mostly frozen in design 5 years later. And WE get flak for not implementing new stuff?

 

Why don't you take it to comp.lang.c ? They surely could use your there :-) They LOVE new feature suggestions, and being explained what to do.

It's like marriage — once you try it, there is no way back. I like Pascal, it's useful for me, but I'm not a fanboy.

[Roman]

There is no need for a combined ":=" and "==" if the language is well designed.

For "==" I agree, but for ":=" not. There is a big difference between an equation ("=") and assignation (":="). By the way the ":=" origins from the character of left arrow "<=", meaning that the result of the right side expression becomes the value of the variable on the left side. The assignation character is missing from all usual keyboards, the "<=" is used for a comparission operator, so ":=" is the best choice for the assignation symbol.

[munair]

As far as loops and many other flow control constructs, it's very unfortunate that so many programmers make their hobby to bash COBOL because, aside from the fact that it is wordy, the control flow constructs it offers are well thought out and, should be used as a guide (which does not mean carrying over their wordiness.)

I am totally unfamiliar with COBOL. But if the wordiness adds to consistency it is certainly justified. For example, in a construct like LOOP DO WHILE it is tempting to leave out DO, but that would connect LOOP WHILE directly to END. Not good.

The only bit of exception is SharpBASIC's IF construct, although there is still logic in that whatever branch is true connects DO..END:

Code: Text  [Select][+][-]

1. if a > 0 do
2.   // ...
3. else if b > 0 do
4.   // ...
5. else if c > 0 do
6.   // ...
7. else do
8.   // ...
9. end;

Note that ELSE IF is not nested; it functions as ELSEIF but it was decided not to add yet another keyword for it as a nested IF would logically follow on ELSE DO.

[munair]

There is no need for a combined ":=" and "==" if the language is well designed.

For "==" I agree, but for ":=" not. There is a big difference between an equation ("=") and assignation (":="). By the way the ":=" origins from the character of left arrow "<=", meaning that the result of the right side expression becomes the value of the variable on the left side. The assignation character is missing from all usual keyboards, the "<=" is used for a comparission operator, so ":=" is the best choice for the assignation symbol.

That very much depends on the language design. The first requirement is that the assignment operator is different from the comparison operator. In the case of Pascal, if the comparison operator is "=" then of course assignment needs to be something else. But if the comparison operator is something like "==" (compare not equal "<>") then a two-character assignment operator seems a little redundant.

Comparison operators are inevitably one and two characters: "<", ">", "/", ">=", "%" etc. So to me "=" is the most neutral assignment operator. But this is very much a matter of taste. Pascal chose to have it the other way around (two-character operator for assignment, and one character operator for comparison), which is fine too.

[440bx]

I don't think so, but you admit that there is something to it.

Yes, I do believe you made worthwhile points. 

But this case exists and should not. All or nothing.

I agree _but_ for quite a number of years now, the Pascal language has been designed by a group of people who are a lot more concerned with making money and staying in business than actually and genuinely improving the language.  That's why, while I think standard committee's are not particularly efficient, they are needed, at least their concern is the language not adding "ornaments" to it to make it look shiny.  That's a significant disadvantage for Pascal. 

To be fair, the FPC developers are to some extent between a rock and a hard place.  Delphi compatibility is still very important for FPC (and Lazarus as well.)

So why we still have no replacement for old school case-style variant records? Nobody want it?

Quite likely that isn't the problem. Look at what is happening in this thread.  Allowing the initialization of a group of variables, which I consider a no-brainer... it's consistent with the initialization of one variable, it's a natural extension of what is already there yet, look at the controversy for something that trivial, now imagine the controversy seriously suggesting creating a different syntax for unions would generate. 

I cannot be sure but, if the evolution of Pascal was in the hands of a standards committee, I think chances would be good that the feature would already exist (initialized variable groups, that is.)

C is old, dirty and unsafe, but fast and concise. I like it.

I avoid it but, I use it.  Generally speaking, most implementations produce generally fast code but, when you consider how much human effort has gone into the language by lots of very talented programmers, the result leaves a great deal to desire.  I cannot say I'm completely sure but, in 40+ years since its creation the amount of effort and talent that has gone into the C language is probably comparable to the amount of effort and talent invested in putting a man on the moon.   Yet, C is more likely to put a man in a debugger than anywhere else.

Honestly, there is not even a single doubt in my mind that a good implementation of Pascal could run rings around any and all implementations of C currently available.   

I am totally unfamiliar with COBOL. But if the wordiness adds to consistency it is certainly justified.

One of COBOL's great features is that you can make everything explicit.  I can't even think of an "implementation dependent" feature of COBOL at this time.  The language is very well thought out but, it has to be acknowledged, it is wordy and, as a business oriented language, it has quite a few limitations but, for design ideas, it's worth checking it out.  I suggest you have a look at how COBOL implements loops and case statements, you might find some interesting ideas in there.

If you do have a look at it, do expect to be disappointed by some of the language's characteristics, ignore those, absorb the good stuff in it.