Recent

Author Topic: C-style assigments and side effects in FPC  (Read 6651 times)

alpine

  • Hero Member
  • *****
  • Posts: 1032
C-style assigments and side effects in FPC
« on: July 12, 2021, 01:11:09 pm »
This post is about a bugtracker issue I've just read, https://bugs.freepascal.org/view.php?id=39206.
It seems that the shorthand assignment operators +=, -=, etc.  in FPC have quite different semantics of that in C/C++ and are simply evaluated as a += b <=> a := a + b.
From the Reference manual:
Quote
13.1.1 Assignments
...
Remark These constructions are just for typing convenience, they don’t generate different code.
At the other hand, for C/C++: https://en.cppreference.com/w/cpp/language/operator_assignment
Quote
The behavior of every builtin compound-assignment expression E1 op= E2 (where E1 is a modifiable lvalue expression and E2 is an rvalue expression or a braced-init-list (since C++11)) is exactly the same as the behavior of the expression E1 = E1 op E2, except that the expression E1 is evaluated only once and that it behaves as a single operation with respect to indeterminately-sequenced function calls.

And for C#: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/assignment-operator
Quote
For a binary operator op, a compound assignment expression of the form
x op= y
is equivalent to
x = x op y
except that x is only evaluated once.

As a bilingual programmer, I find this quite misleading (see the bugtracker issue). Assignments like a[f()] += b; will evaluate the left-hand expression twice thus doubling f()'s side effects if any.
In C/C++ very common practice is to write things like:
Code: C  [Select][+][-]
  1. a[i++] += b[j++];

Personally, I'm avoiding the use of any C-style tricks in my Pascal sources just to maintain a clear distinction between them and the C's. My question actually is why a C-like feature was introduced in FPC but not with the same semantics? Anybody has an opinion? May be the compiler guys?
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: C-style assigments and side effects in FPC
« Reply #1 on: July 12, 2021, 01:27:37 pm »
Personally, I'm avoiding the use of any C-style tricks in my Pascal sources just to maintain a clear distinction between them and the C's. My question actually is why a C-like feature was introduced in FPC but not with the same semantics? Anybody has an opinion? May be the compiler guys?

They were introduced back then by someone (don't know who had the idea) who wanted to simply type less. They are simply syntax sugar, nothing more, nothing less and aren't a favourite among the core devs (we disallow them inside the compiler source for example). Nowadays a feature like that simply wouldn't be added (back then we were a bit less strict). And no, we don't want to "improve" them either.

alpine

  • Hero Member
  • *****
  • Posts: 1032
Re: C-style assigments and side effects in FPC
« Reply #2 on: July 12, 2021, 02:28:53 pm »
*snip*
And no, we don't want to "improve" them either.
Thanks for your answer! IMHO, because they confuse the C-people (who would actually use them), I think they should be removed.
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: C-style assigments and side effects in FPC
« Reply #3 on: July 12, 2021, 02:59:55 pm »
*snip*
And no, we don't want to "improve" them either.
Thanks for your answer! IMHO, because they confuse the C-people (who would actually use them), I think they should be removed.

Bravo!!!!

Winni

Kays

  • Hero Member
  • *****
  • Posts: 569
  • Whasup!?
    • KaiBurghardt.de
Re: C-style assigments and side effects in FPC
« Reply #4 on: July 12, 2021, 05:37:10 pm »
[…] Assignments like a[f()] += b; will evaluate the left-hand expression twice thus doubling f()'s side effects if any. […]
Oh dear, that can be indeed confusing if you, as a C programmer, expect something else.
[…] They were introduced back then by someone […] who wanted to simply type less. […]
Too bad we can’t blame “someone”. According to whatsnew.txt it’s been added in 1.9.8. The migration CVS→SVN apparently occurred at/after 2.0.0 and I don’t find the CVS (if it is even available somewhere).
[…] I think they should be removed.
Well, I think as an intermediate step {$COperators off} should become the new default setting for a grace period before it’s actually removed.
Yours Sincerely
Kai Burghardt

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: C-style assigments and side effects in FPC
« Reply #5 on: July 13, 2021, 09:55:53 am »
*snip*
And no, we don't want to "improve" them either.
Thanks for your answer! IMHO, because they confuse the C-people (who would actually use them), I think they should be removed.

As much as I'd like to do so, they will not be removed due to backwards compatibility.

[…] They were introduced back then by someone […] who wanted to simply type less. […]
Too bad we can’t blame “someone”. According to whatsnew.txt it’s been added in 1.9.8. The migration CVS→SVN apparently occurred at/after 2.0.0 and I don’t find the CVS (if it is even available somewhere).

The COperators directive was added then, but the C operators themselves are much older. Though due to some hickups in the CVS history it's hard to follow when exactly it was added and by whom and even then this does not mean that it was initiated by a dev, but instead by a user.

[…] I think they should be removed.
Well, I think as an intermediate step {$COperators off} should become the new default setting for a grace period before it’s actually removed.

COperators Off is the default as far as the compiler is concerned. The fpc.cfg includes the -Sc. Also this will not change due to backwards compatibility.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: C-style assigments and side effects in FPC
« Reply #6 on: July 13, 2021, 10:26:30 am »
"...the expression E1 is evaluated only once and that it behaves as a single operation with respect to indeterminately-sequenced function calls."

Noting what other people have said about how long this bit of syntactic sugar has been in FPC, I think it's fair to ask when C actually specified that E1 was evaluated precisely once: I don't think it was in K&R, I'm not sure whether it was in late-80s ANSI, and at that point FPC can hardly be criticised for not complying with something which had been slipped into C's specification at about the same time as it was first being written.

Speaking personally, I'm OK with concise operators PROVIDED that everybody understands the extent to which they're effectively a macro as distinct from something with distinct semantics. If FPC defines that E1 may be evaluated more than once or that it's implementation-specific (i.e. dependant on the vagaries of the optimiser) that's entirely fair, and the joke's on the C community and their initially-sloppy design.

MarkMLl


MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Blade

  • Full Member
  • ***
  • Posts: 177
Re: C-style assigments and side effects in FPC
« Reply #7 on: July 13, 2021, 10:45:53 am »
*snip*
And no, we don't want to "improve" them either.
Thanks for your answer! IMHO, because they confuse the C-people (who would actually use them), I think they should be removed.

Sorry, but disagree.  As they have already been around for quite a while, a percentage of people have already used them and are aware to be careful.  I think maybe only a warning or more detailed help explanation should be given.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11352
  • FPC developer.
Re: C-style assigments and side effects in FPC
« Reply #8 on: July 13, 2021, 11:29:07 am »
The COperators directive was added then, but the C operators themselves are much older. Though due to some hickups in the CVS history it's hard to follow when exactly it was added and by whom and even then this does not mean that it was initiated by a dev, but instead by a user.

I think Peter in 0.99.x  with x=10,12,14, which were kind of like the 1.9.x series for 1.0.x.

Motivation was afaik error avoidance while converting C code, not usage in new pascal code, specially while loops. I suspect he was thinking of doing a new zlib port, rather than debugging the paszlib one. (which also supported 16-bit and was kept TP compatible)

It would maybe help to drive the message home if we removed the usage as much as possible. Afaik Lazarus uses it, FPC not so much.


Thaddy

  • Hero Member
  • *****
  • Posts: 14169
  • Probably until I exterminate Putin.
Re: C-style assigments and side effects in FPC
« Reply #9 on: July 13, 2021, 12:05:21 pm »
FYI

I asked for just this that (increment after use) but it was refused.
Specialize a type, not a var.

alpine

  • Hero Member
  • *****
  • Posts: 1032
Re: C-style assigments and side effects in FPC
« Reply #10 on: July 13, 2021, 12:52:23 pm »
"...the expression E1 is evaluated only once and that it behaves as a single operation with respect to indeterminately-sequenced function calls."
Noting what other people have said about how long this bit of syntactic sugar has been in FPC, I think it's fair to ask when C actually specified that E1 was evaluated precisely once: I don't think it was in K&R, I'm not sure whether it was in late-80s ANSI, and at that point FPC can hardly be criticised for not complying with something which had been slipped into C's specification at about the same time as it was first being written.

page 46, Kernighan, Brian; Ritchie, Dennis (1978). The C Programming Language (1 ed.)
Quote
2.10 Assignment Operators and Expressions

Expressions such as
i = i + 2

in which the left hand side is repeated on the right can be written in the
compressed form

i += 2

using an assignment operator like +=.

Most binary operators (operators like + which have a left and right
operand) have a corresponding assignment operator op=, where op is one of

+ - * / % « » & ~ |

If el and e2 are expressions, then

el op= e2

is equivalent to

el = (el ) op (e2 )

except that el is computed only once.

AFAIK, it is Algol68 inspired (+:=).
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: C-style assigments and side effects in FPC
« Reply #11 on: July 13, 2021, 12:58:38 pm »

page 46, Kernighan, Brian; Ritchie, Dennis (1978). The C Programming Language (1 ed.)

"except that el is computed only once."

AFAIK, it is Algol68 inspired (+:=).

Thanks for that, and apologies for my earlier misleading statement.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

alpine

  • Hero Member
  • *****
  • Posts: 1032
Re: C-style assigments and side effects in FPC
« Reply #12 on: July 13, 2021, 02:21:01 pm »
@MarkMLl
Apologies accepted.

@Blade
*snip*
Sorry, but disagree.  As they have already been around for quite a while, a percentage of people have already used them and are aware to be careful.  I think maybe only a warning or more detailed help explanation should be given.
Until recently, I didn't even know they existed. It's weird that something so C-ish slipped through. (but marcov has already given some plausible explanation)

In my education Pascal came first, and then C, and although now I often use both in a same project, I'd never use x+=1 in Pascal, but rather Inc(x) or even x:=x+1. But that's me. I suspect a C-taught programmer will use a shorthand wherever possible. That is why I think they should work either the same way or be removed.
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11352
  • FPC developer.
Re: C-style assigments and side effects in FPC
« Reply #13 on: July 13, 2021, 02:58:49 pm »
MarkMLI: note that this situation was one of the reasons I suggested to Benjamin to confine interoperability features to the import modules (the modules directly interfacing to <x>) in R10 .

The problems (usage outside the realm they were meant for, slipping into the general dialect) were not new to him, he already planned to confine them.

 

TinyPortal © 2005-2018