Why does Free Pascal use a colon in its assignment operator?

[blackangel]

When learning Free Pascal, entering := feels cumbersome. The vast majority of modern programming languages use just a single equals sign for assignment.
Could the compiler be adjusted to accept both := and = as valid assignment syntax? 

[marcov]

When learning Free Pascal, entering := feels cumbersome.

The original reason is that it is not an equality in the mathematical sense.  It is more a "becomes" than an equality (comparison).

Pascal uses a single = for comparison.

The vast majority of modern programming languages use just a single equals sign for assignment.

But many suffer from ugliness as == for comparison. 

The lack of variation in recent languages has nothing to do with language design, but that new languages
are mostly created by corporations that hope to save on retraining. (which is a bit stupid, since base language
syntax has been shown not to be a factor in learning for a new job. Application Frameworks are usually the biggest hurdle)

Could the compiler be adjusted to accept both := and = as valid assignment syntax? 

No.

[CM630]

Look it from the good side.
In Arduino (some kind of C):
= is what is := in fpc.
== is what it = in fpc.

if a = b compiles doing shit in Arduino, but if a := b does not compile in fpc and this is really, really good.

[LemonParty]

This is not the only thing to mention.
Beside = as assignment in modern languages you can see the zoo of operators like

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

1. & && | ||

When in Pascal those operators present in a single form:

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

1. and or

This is a plus of language that you can't combine boolean and bit operations. It protects from potential bugs.

[marcov]

This is a plus of language that you can't combine boolean and bit operations. It protects from potential bugs.

I think this is due to not allowing boolean operators on INTs. This avoids automatic conversion of binary types to be interpreted as a boolean, and that causes the ambiguity that needs two sets of operators in C.

[Curt Carpenter]

I think  :=   evolved from the Backus naur meta-language ::=   ("is replaced by") which was used in the formal definition of Algol 60.  Algol 60 adopted  :=  for assignment, and I suspect it entered into Pascal from there. 

I always liked the fact that Algol and Pascal respected the mathematical heritage of the =  .   

[creaothceann]

entering := feels cumbersome

It becomes muscle memory, just like begin/end/etc. (For some reason Pythons omission of those seems to make programmers angry too...)

[440bx]

Could the compiler be adjusted to accept both := and = as valid assignment syntax? 

No.  Attempting to use = as a way to assign in Pascal would create a large number of ambiguities in the language.

equality and assignment are two very, very different things.  Unfortunately, in non-programming contexts, their distinction is much too often ignored.  In programming languages that difference/distinction cannot be ignored.

[MarkMLl]

When learning Free Pascal, entering := feels cumbersome. The vast majority of modern programming languages use just a single equals sign for assignment.

All modes of FPC use that syntax because FPC is an implementation of Pascal, not of FORTRAN or BASIC.

Pascal uses := because it is a derivative of ALGOL, the same notation is used by both CPL and BCPL. Pascal derivatives including the Modula family and Ada also use it, as do VHDL and IEC61131 "Structured Text" which are both Ada derivatives.

ALGOL originally used a left-arrow for assignment, which was available in many of the pre-ASCII character sets (and in fact in ASCII prior to the 1965 revision). As an alternative, := was defined in the ALGOL-58 specification.

During the earliest days of IAC/ALGOL standardisation, some of the European delegates favoured a "rightwards" assignment indicated either by => or by a non-standard glyph, see https://en.wikipedia.org/wiki/Plankalk%C3%BCl#Assignment_operation

Could the compiler be adjusted to accept both := and = as valid assignment syntax? 

Changing it is out of the question, and in fact I'd prefer to see == for comparison with an unembellished = being an error in all cases.

MarkMLl

[Warfley]

This is not the only thing to mention.
Beside = as assignment in modern languages you can see the zoo of operators like

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

1. & && | ||

When in Pascal those operators present in a single form:

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

1. and or

This is a plus of language that you can't combine boolean and bit operations. It protects from potential bugs.

Well actually the C operators are better designed and the pascal ones, because C has the distinction between the bitwise operations | and & and the short circuit boolean operations || and &&

This has many advantages. First the boolean versions || and && always return a valid book (I.e. 0 or 1) and never any bitops that can give very weird results.
Second you can explicitly target short circuit and full evaluation within code without having to use weird compiler switches. How many times I had to write

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

1. {$Push}
2. {$B+}
3. If ... Then
4. {$Pop}

Is really annoying and in C I can just express this as part of the expression.

But more importantly, they have different operator precedence. The bool versions || and && have a low priority, making it easy to chain comparisons

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

1. if (a==42 && b>=3.14) ...

And the bitops have a high priority which makes bitmaps and bitops easy:

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

1. if (bmp & 1 == 0 || b>=3.14)

In pascal you only have one operator with high precendece for both, so you must write

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

1. if (bmp and 1 = 1) or (b>=3.14) then

In pascal you always need to add brackets around each comparison because and and or have auch a high priority.

And btw. even Pascal developers agreed with this. In the extended pascal ISO standard NRW operators and_then and or_else have been introduced in addition to and and or to make short circuit evaluation part of the language explicitly.

Personally I like the python approach most, they use & and |  for bitwise and "and" and "or" for short circuit bools

[slicke]

:= is supposed to look like an arrow, I was taught

so := would be like ->

a becomes b

a := b

[J-G]

[...] making it easy to chain comparisons

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

1. if (a==42 && b>=3.14) ...

And the bitops have a high priority which makes bitmaps and bitops easy:

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

1. if (bmp & 1 == 0 || b>=3.14)

To me that is totally unitelligible !   even writing it initially  -  what the brain might fathom when reviewing such gibberish after a number of years is beyond comprhension.

In pascal you only have one operator with high precendece for both, so you must write

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

1. if (bmp and 1 = 1) or (b>=3.14) then

In pascal you always need to add brackets around each comparison because and and or have auch a high priority.

Never having seen that 'third party' code previously, it is totally understandable - thought I will admit that knowledge of logical 'and' is required 
. . . and that is why I stick to a language that can be understood with very little 'Comment' about what is intended.

[440bx]

:= is supposed to look like an arrow, I was taught

so := would be like ->

a becomes b

a := b

Actually, if using an arrow then := would be <- since it is the LHS that is affected by the assignment.

a <- b;  { value of b assigned to variable a }

On a related but separate note, that justifies Intel's ASM syntax, where the destination is usually (probably always) on the LH.

[jamie]

Look it from the good side.
In Arduino (some kind of C):
= is what is := in fpc.
== is what it = in fpc.

if a = b compiles doing shit in Arduino, but if a := b does not compile in fpc and this is really, really good.

Lets c, if memory serves me well, I could do this in C

if (AVar = Function(......))
 {......}

With that I can assign AVar and the results is used for the IF expression.

Also, in C, all items are treated like booleans if not compared against another type using IF operator.

if SomeVarOfAnyType {......}

That is treated as a Boolean.

Its all good if you understand what's happening but it can also lead someone astray not knowing both languages.

Jamie.

[Warfley]

In pascal you always need to add brackets around each comparison because and and or have auch a high priority.

But dont you think that the same construct having different functions is not confusing? Like

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

1. if (bmp and mask <> 0) and (bmp and mask2 <> 0) then

You have the same operator doing completely different things. I personally think that features that are semantically very different should also syntactically be different.