Dfn Bug or Feature?
4 posts
• Page 1 of 1
Dfn Bug or Feature?
Consider:
And then this seemingly equivalent dfn:
And their respective results:
Is this a long-standing and well-known feature of dfns? If we replace the f with the literal primitive "+" then the dfn works like the trad function. Or is is a bug? Obviously something to do with the different way assignments are handled in dfns...
z←Trad;f;a;w
f←+
a←2
z←a f w←1 2 3
And then this seemingly equivalent dfn:
Dfn←{
f←+
a←2
z←a f w←1 2 3
z
}
And their respective results:
Trad
3 4 5
Dfn 0
1 2 3
Is this a long-standing and well-known feature of dfns? If we replace the f with the literal primitive "+" then the dfn works like the trad function. Or is is a bug? Obviously something to do with the different way assignments are handled in dfns...
- paulmansour
- Posts: 420
- Joined: Fri Oct 03, 2008 4:14 pm
Re: Dfn Bug or Feature?
A long standing feature?
Yes indeed. From the very beginning. Any assignment to a simple name within a dfn creates a new entity within the scope of the "capsule".
Unlike within a tradfn or in the session, the prohibition on certain changes of nameclass; for instance: function to array; is avoided by each new assignment to a particular name shadowing the previous.
The parsing is therefore slightly different in that in your example with "f" being a function and outside of a dfn
Yes indeed. From the very beginning. Any assignment to a simple name within a dfn creates a new entity within the scope of the "capsule".
Unlike within a tradfn or in the session, the prohibition on certain changes of nameclass; for instance: function to array; is avoided by each new assignment to a particular name shadowing the previous.
The parsing is therefore slightly different in that in your example with "f" being a function and outside of a dfn
a f w←1 2 3is parsed as
a f (w←1 2 3)whereas within a dfn it's as
(a f w)←1 2 3with the parenthesised part being entirely in the "name" domain.
-
Phil Last - Posts: 628
- Joined: Thu Jun 18, 2009 6:29 pm
- Location: Wessex
Re: Dfn Bug or Feature?
Thanks Phil.
I'm not too concerned as this issue only came up as I was converting a whole bunch of trad functions to dfns under program control. I would not write code this way.
The moral of the story I think is that one should avoid embedded assignment.
Be that as it may, it's a little disconcerting that simply naming a primitive changes the way a dfn parses a line.
I'm not too concerned as this issue only came up as I was converting a whole bunch of trad functions to dfns under program control. I would not write code this way.
The moral of the story I think is that one should avoid embedded assignment.
Be that as it may, it's a little disconcerting that simply naming a primitive changes the way a dfn parses a line.
- paulmansour
- Posts: 420
- Joined: Fri Oct 03, 2008 4:14 pm
Re: Dfn Bug or Feature?
Sorry to argue with you Paul, but it's not in the dfn that the difference appears.
In a dfn the prior existence of any of the three names affects it not at all.
Today, an unambiguous coding, assuming one isn't put off by embedded assignment, might be
a b c←0 1 2was available as a stranded assignment before the advent of dfns and generally expected to result in the creation of three scalar arrays. Executing
⎕FX↑,↓'r←a b w'prior to the assignment changed the parsing of the statement such that, assuming "a" already exists, "c" becomes a three item vector that function "b" takes as right argument.
In a dfn the prior existence of any of the three names affects it not at all.
Today, an unambiguous coding, assuming one isn't put off by embedded assignment, might be
a b⊢c←1 2 3
-
Phil Last - Posts: 628
- Joined: Thu Jun 18, 2009 6:29 pm
- Location: Wessex
4 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group