Inconsistencies with available assignment operators

[lukebemish]

Most of the basic "arithmetic" operators support assignment operators, where something like a += 5 is equivalent to a = a + 5. However, the presence of these seems to be somewhat inconsistent and a couple useful use-cases are missing. One use case I've ran into recently, when working with immutable structures, is wanting to update the value of a variable in-place in a similar fashion, but when applying arbitrary functions. For instance, something like

a = f(a)

or even

a = f(g(a))

The |> operator makes the latter a bit nicer to express, as

a = a |> g |> f

But it would be convenient to be able to do something like

a |>= g ∘ f

or the like instead. Furthermore, there are inconsistencies even among the more "normal" infix operators in terms of which support assignment operators; while ⊼, ⊽, and ⊻ are all infix operators (giving bitwise nand, nor, and xor respectively), only ⊻= is a valid assignment operator, which feels wacky.

[Keno]

Furthermore, there are inconsistencies even among the more "normal" infix operators in terms of which support assignment operators; while ⊼, ⊽, and ⊻ are all infix operators (giving bitwise nand, nor, and xor respectively), only ⊻= is a valid assignment operator, which feels wacky.

These are probably just missing from the list in the parser, might as well have them.

[Keno]

a |>= g ∘ f

It's quite clever, because it's consistent with the ordinary meaning of our infix update, but I do worry it's a bit too magical.

[adienes]

I vote no, please, to |>=. nice idea but it's way too "cute" & confusing imo.

[lukebemish]

Is there a reason not to just have assignment operators for every infix operator where it wouldn't cause ambiguity? (That is, not < and company). The current list feels a bit arbitrary to be honest.

[adienes]

I guess define "ambiguous" ? >= <= and != throw a lot of wrenches into a lot of gears trying to describe some "rule" so I'd say it's more art than science

I don't think any of us want to see x !=== y mean x = (x !== y)

[lukebemish]

Simplest in my mind would be to make an equivalent assignment operator for every operator that's an actual function, so excluding"control flow" that's effectively not evaluated like an infix operator (&&), comparison operators in general (since (a) if it returns a boolean, in-place updates aren't useful or intuitive, and (b) they're likely to be confusing), or those operators for which the assignment operator might have some other implied meaning (:, for instance). At any rate, you're right that it's more art than science -- hence why I think the best approach is just to provide an assignment operator for every operator where doing so isn't immediately useless or problematic. Otherwise, providing them for only a small subset is rather arbitrary -- especially when that subset already includes operators many folks may not recognize right off the bat, or use at all, like ⊻.

For reference, the available assignment operators at present seem to be:

+= -= *= /= //= \= ^= ÷= %= <<= >>= >>>= |= &= ⊻= $=

As well as := ≔ ⩴ ≕ being apparently specially reserved and giving an "unsupported assignment operator" error. While for the most part these make sense, there is already a fair amount of arbitrariness to these (⊻, $ which currently has no definition in Base), and I think its worthwhile to add assignment operators for the other infixes where doing so doesn't cause issues.

[JeffBezanson]

while ⊼, ⊽, and ⊻ are all infix operators (giving bitwise nand, nor, and xor respectively), only ⊻= is a valid assignment operator

That looks like an oversight; we should just add them.

[StefanKarpinski]

Would also love to have ∨= and ∧= as well as ∪= and ∩=.

[adienes]

I agree all of those are super reasonable; my being a hater extends only to |> and all the comparison operators