0 sats \ 1 reply \ @l0k18 27 Jun 2023
Technically, side effects are where you get a result you don't intend, as the central, not side effect. They are caused by a function storing state unknown to the caller, causing a non-deterministic execution given the same starting conditions.
Changing a variable is an expected outcome of a function, just maybe the functional nutters don't realise that call by value is not practical in every use case. And it's a dodge anyway, of course it has no "side effects" if it doesn't have internal state that alters its mutation/processing of data from input to output.
Imo, it would be better to make a formal Assembler syntax for it, and steal the whole macro system from it as well to do the abstraction and word-to-memory offset trtanslation.
reply
0 sats \ 0 replies \ @l0k18 28 Jun 2023
I may be a bit confused because I adopted a language that uses concurrent sequential processes - atomic FIFO queues and coroutines, to me, mutating variables is not the problem, it's when two threads mutate the same variable or one mutates one reads and the program will panic or behave unpredictably. In this paradigm we accept that it's often better to pass by reference but that it's never ok for two threads or more to handle a mutable value. (in Go, only strings are immutable).
reply