Semantics of+= and the like

[z-rui]

In the documentation of +=, it's unspecified whether x is evaluated once or twice:

    (+= x & ns)

    Increments the var x by n.

Although for *=, it seems to imply that x is evaluated twice:

    (*= x & ns)

    Shorthand for (set x (* x n)).

Because x may be an indexing expression, this can sometimes cause problems, like doubling the side effect or inefficient bytecode. E.g.,

(+= (x (inc i)) 42)

Here inc will be called twice.

Would it be more reasonable to change/clarify the spec so that the lvalue is only evaluated once? This matches the expectation from most users, and aligns with other languages that have this kind of shorthand. I think it can be achieved by defining those macros as

(defn- op-assign-temlate [op x & ys]
  (match x
    [ds i] (with-syms [DS I]
             ~(let [,DS ,ds ,I ,i]
                (set (,DS ,I) (,op (,DS ,I) ,;ys))))
    ~(set ,x (,op ,x ,;ys))))

(defmacro += [x & ys] (op-assign-temlate + x ;ys))
# etc.

[sogaiu]

For +=, the docstring mentions:

Increments the var x by n.

I'm not sure I would interpret that to be intentionally allowing (x (inc i)) to be something one can consider an instance of "var x".

I don't know what the intent is, just making a 3rd party observation 😅

---

FWIW, I'm not opposed to the proposed changes.

---

Note: I removed an earlier comment which I think may have been incorrect.

[primo-ppcg]

I'm inclined to agree, mostly as a matter of principle.

repl:1:> (def x @[1 2 3])
@[1 2 3]
repl:2:> (var i 0)
0
repl:3:> (+= (x (++ i)) 10)
13
repl:4:> x
@[1 2 13]
repl:5:> i
2

I think this is a surprising result. Perhaps the underlying issue here is that (x (++ i)) isn't really an l-value, although I do think it's reasonable for the key to be a expression - and also a reasonable expectation that that expression only be evaluated once.

It should be noted that these are very primitive macros, which collectively are used dozens of times in the core implementation. Higher level macros (match, with-syms, and even let) cannot be used, as they are yet to be defined. Some care should also be taken not to generate excessive code or symbol definitions if unnecessary.

A roughly equivalent implementation to the one proposed (with reference to the implementation of set:

(defn- op-assign-template [op x & ys]
  (if (= (tuple? x) (= 2 (length x)) true)
    (do
      (def [ds key] x)
      (def $ds (gensym))
      (def $key (gensym))
      ~(do
        (def ,$ds ,ds)
        (def ,$key ,key)
        (set (,$ds ,$key) (,op (,$ds ,$key) ,;ys))))
    ~(set ,x (,op ,x ,;ys))))

This could be cleaned up a bit. $ds should likely only be generated if ds is not already a symbol, and $key only if key is not idempotent.

[pepe]

I would be cautious about changing such a fundamental functionality, even if it is perceived as faulty. Just my 2 cents, tho.

[primo-ppcg]

I would be cautious about changing such a fundamental functionality, even if it is perceived as faulty. Just my 2 cents, tho.

I agree. However, that doesn't mean it can't or shouldn't be done, just that caution should be excercised.

[bakpakin]

Usually I would say that changing behavior like this is not a good idea, but in this particular case, I think it makes sense as the fix is pretty general and I think almost complete harmless.