False negative

[Phil Last]

> 18634: Logged or Updated (Versions: 17.0) 2020-11-09
> In a dfn, selective modified assignment like (2⊃r)fn←0 can overwrite helper dfn fn

I note that this uses the surprising word "can". Surely it always does so when a function is named rather than defined in situ or braced:

      (2⊃r)fn←0

vs

      (2⊃r){⍺ fn ⍵}←0

It certainly should.

It also specifies "Logged or Updated".

Please can we be assured that issue 18634 remains logged or updated and that no attempt is made to "Fix" this feature which is absolutely consistent with the behaviour of dfns as they have existed since Dyalog V8.0 1993(?).

[StefanoLanzavecchia]

If we go by absolutes then it "certainly should not". Why? Principle of least surprise.
The same code behaves wildly differently in a tradfn and in a dfn. Which means that if you put curly braces around a few lines of code which worked perfectly makes them stop working. No, please no. That's horrible.

[Morten|Dyalog]

Please can we be assured that issue 18634 remains logged or updated and that no attempt is made to "Fix" this feature which is absolutely consistent with the behaviour of dfns as they have existed since Dyalog V8.0 1993(?).

Hi Phil! Are you saying you have code which depends on this behaviour?

[Phil Last]

I almost certainly have code that is similar to

      (expr)name←value

where both (expr) and name are in the "name domain". In which case dfn syntax dictates that it is the target for the assignment of a two item vector whatever their previous nameclass and value.

[Phil Last]

and I doubt that I'm alone in that.

[StefanoLanzavecchia]

I found this à-propos: http://help.dyalog.com/18.0/#Language/Primitive%20Operators/Assignment%20Modified.htm?Highlight=assignement. It does not say that dfns should behave differently.

Edit: never mind. I found it: http://help.dyalog.com/18.0/#Language/Defined%20Functions%20and%20Operators/DynamicFunctions/Restrictions.htm.

From which I quote: "dfns do not support modified assignment such as X plus←10 where X is an array and plus is a function. In this example, both X and plus would be assigned the value 10."

I'll admit, I had never noticed this note. And I claim it's got nothing to do with rules related to the definition of assignment in dfns. But, fair enough.

[StefanoLanzavecchia]

The restriction was first documented with Dyalog 15.0. It wasn't there previously: http://help.dyalog.com/14.0/#Language/D ... ctions.htm

Not that I am blaming Dyalog for not pointing out in the release notes something that was not a change in the actual behaviour but only a formalisation of an existing "feature". But unless somebody had run into it, my claim is that the page about modified assignment should have been authoritative on the subject. And that page does not say anything about the rule not being valid for dfns.

This said, we certainly do not rely on a behaviour which I consider broken. And we were bitten only once by it. And yes, we were the ones who reported it as something not so much to fix, but to consider for revision.

[Phil Last]

I exaggerated the age of dfns:

Dfns were introduced with APL/W version 8.1 release 1 in early 1997.

But note that this was well before the introduction of the form of modified assignment that made:

      x y←z

ambiguous elsewhere dependent on the prior nameclass of y. Before that change it was consistent within dfns and a syntax error elsewhere if y was a function.

But another valid construction of the above was changed in the introduction of dfns in that therein:

      x y←z

could not mean:

function x applied to y which is z

which always was and still is the case elsewhere.

[jayfoad]

Phil, it is interesting that dfns predate x f←y being accepted as a modified assigment. I didn't know that.

Regardless, I think there is no good reason for the difference in behaviour between dfns and tradfns. The difference comes from the fact that an assignment in a dfn looks ahead to try to identify which names will be assigned to, so it can localise them before doing the assignment. It is in my opinion a failing of this look-ahead code that it does not handle all forms of assignment the same as in a tradfn. But I guess it's too late to change it now.

It is tempting to think that all these problems would have been avoided if Dyalog had insisted from day 1 that the LHS of a strand assignment had to be parenthesised:

      (x y)←... ⍝ strand assignment
      x y←... ⍝ would be parsed as x(y←...)

But I'm not sure that's true. There would still be cases like this:

      x(y z)←... ⍝ ???

Sure, you would know that this is not strand assignment to x(y z); but it could still be modified assignment to x if z was a monadic operator.

[Adam|Dyalog]

Wow, I didn't know about that chronology either. Thank you for enlightening me.

In hindsight, when we added modified assignment, it might have been a good idea to require the syntax

      x(f←)z

which would be unambiguous. Of course, it isn't too late to allow this.

I believe that with both this additional restriction and requiring parenthesis for multiple assignment, auto-localisation doesn't preclude modified assignment or using the pass-through value:

      ⍝ Examples assuming parentheses are required for both strands and modified assignments:
 f x ← a  ⍝ use of pass-through value
(x y)← a  ⍝ strand assignment
 x(f ←)a  ⍝ modified assignment

 x f  y ← a  ⍝ use of pass-through value
(f g) x ← a  ⍝ use of pass-through value
 f(x  y)← a  ⍝ use of pass-through value from strand assignment
 f x (g ←)a  ⍝ use of pass-through value from modified assignment

(x y)(g ←)a  ⍝ modified strand assignment
(x y  z)← a  ⍝ strand assignment
 x(f  o ←)a  ⍝ modified assignment with derived function

 f x  g  y ← a  ⍝ use of pass-through value
 x f  y (g ←)a  ⍝ use of pass-through value from modified assignment

(f g) h  y ← a  ⍝ use of pass-through value
 x(f  g) y ← a  ⍝ use of pass-through value
 x f (y  z)← a  ⍝ use of pass-through value from strand assignment
 f x (f  g ←)a  ⍝ use of pass-through value modified assignment with derived function

(f g) y (h ←)a  ⍝ use of pass-through value from modified assignment
(f g)(x  y)← a  ⍝ use of pass-though value from strand assignment
(x y)(f  g ←)a  ⍝ modified strand assignment with derived function

(f g  h) x ← a  ⍝ use of pass-through value
 f(x  y  z)← a  ⍝ use of pass-through value from strand assignment
 x(f  g  h ←)a  ⍝ modified assignment with derived function
(x y  z)(f ←)a  ⍝ modified strand assignment

While we (kind-of) don't currently allow named functions doing the selection in selective assignment, this scheme doesn't solve that problem: (f x)←a vs (x y)←a