[fpc-devel] Proposal: Enhanced replacement for assignment operators

[Ralf A. Quint]

At 11:23 AM 8/6/2010, _-jane-_ at web.de wrote:
>Hello all!
>
>It seems like I have hit a very hot spot with my proposal - they 
>must be something worth...
>Let me recapitulate and once more comment on this.
>
>My proposal is to replace the operators "op=" by one operator "op" 
>and a following ":=".
>This can be further enhanced to work together with my other proposal 
>"Multiple assignments".
>
>Examples:
>
>a + := 1;
>a + := pi; // float
>a + := 'bla'; // string
>a + := [1,2]; // set
>a < := b; // booleans, this is ugly but should be OK (but not with 
>C-style operators), see PS
>a div := 3;
>a or := b;
>a xor := 3;
>a shl := 1;
>f()^ + := 1; // f might have side-effects!
>a[i+j] * := 2; // @a[i+j] only evaluated once
>
>a,b + := c+d; // c+d only evaluated once
>a,b shl := 1;
>a^.b[f(i)], c^.d[g(j)] +:= h(k); // f,g,h might have side-effects, 
>stuff evaluated only once
>
>
>I object to the existing operators += -= /= *= because:
>* the assignment nature is absent (i.e. the ":=" is missing), worse, 
>"=" is the comparison operator
>* every operator of this list introduces a new operator, i.e. all of 
>them are real distict operators
>* the list is incomplete: several operators are missing
>* this syntax it is not really extensible: "mod=" and the like are 
>not expressable as one symbol
>
>Borland's alternative inc/dec/include/exclude is no better since 
>they introduce a flood of names and hide the operator nature.
>
>There are some reasons for my solution:
>* You still see that there is an assignment
>* No new operators: just combinations of an existing a binary 
>operator and ":="
>* Extendability: Any suitable (existing) binary operator can be 
>used, even worded ones, self-defined (overloaded) and properties
>
>The main reason for the proposal is not saving keystrokes but 
>functionality and speed. It is meant to be an optimizing aid to the 
>compiler being able to omit the common expression optimizer in this 
>case without loss and to avoid side-effects. All parts of the 
>statement should be evaluated once. Saving keystrokes and avoiding 
>to write things twice are welcome side-effects.
>This has also been the reason for including these: inc dec include 
>exclude += -= *= /=
>I have often missed e.g. "* :=" and "shl :=".
>
>Semantic of "a op := expr":
>p:=@a; // only once!
>p^:=p^ op expr;
>
>Semantic of "obj.prop op := expr":
>p:=@obj; // address of object, only once!
>p^.prop:=p^.prop op expr; // access property
>
>Semantic of "a,b := expr":
>tmp:=expr; // only once!
>a:=tmp;
>b:=tmp;
>
>Semantic of "a,b op := expr":
>tmp:=expr; // only once!
>p:=@a; // only once!
>p^:=p^ op tmp;
>p:=@b; // only once!
>p^:=p^ op tmp;
>
>BTW: "a[random(2)] + := 1" is not equivalent to "a[random(2)] := 
>a[random(2)] + 1" due to the side-effect of random()!
>
>Best regards
>Jasper
>PS: Using comparison operators on booleans (e.g. "if a=true then 
>...") should produce at least a hint due to bad style!

How long are you programming in Pascal? You are aware that this is a 
list about an implementation of the Pascal programming language, right?

Ralf