False negative
15 posts
• Page 1 of 2 • 1, 2
False negative
On 2020-12-02 11:02, Dyalog DSS Service wrote:> 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←0vs
(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(?).
-
Phil Last - Posts: 628
- Joined: Thu Jun 18, 2009 6:29 pm
- Location: Wessex
Re: False negative
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.
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.
-
StefanoLanzavecchia - Posts: 113
- Joined: Fri Oct 03, 2008 9:37 am
Re: False negative
Phil Last wrote: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?
-
Morten|Dyalog - Posts: 460
- Joined: Tue Sep 09, 2008 3:52 pm
Re: False negative
I almost certainly have code that is similar to
(expr)name←valuewhere 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 - Posts: 628
- Joined: Thu Jun 18, 2009 6:29 pm
- Location: Wessex
Re: False negative
and I doubt that I'm alone in that.
-
Phil Last - Posts: 628
- Joined: Thu Jun 18, 2009 6:29 pm
- Location: Wessex
Re: False negative
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.
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 - Posts: 113
- Joined: Fri Oct 03, 2008 9:37 am
Re: False negative
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.
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.
-
StefanoLanzavecchia - Posts: 113
- Joined: Fri Oct 03, 2008 9:37 am
Re: False negative
I exaggerated the age of dfns:
But another valid construction of the above was changed in the introduction of dfns in that therein:
But note that this was well before the introduction of the form of modified assignment that made:John Scholes wrote:Dfns were introduced with APL/W version 8.1 release 1 in early 1997.
x y←zambiguous 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←zcould not mean:
which always was and still is the case elsewhere.function x applied to y which is z
-
Phil Last - Posts: 628
- Joined: Thu Jun 18, 2009 6:29 pm
- Location: Wessex
Re: False negative
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:
But I'm not sure that's true. There would still be cases like this:
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.
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.
- jayfoad
- Posts: 5
- Joined: Wed May 29, 2019 1:51 pm
Re: False negative
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
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:
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
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
-
Adam|Dyalog - Posts: 143
- Joined: Thu Jun 25, 2015 1:13 pm
15 posts
• Page 1 of 2 • 1, 2
Return to Functional Programming
Who is online
Users browsing this forum: No registered users and 1 guest
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group