Dfn Bug or Feature?

[paulmansour]

Consider:

      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...

[Phil Last]

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

      a f w←1 2 3

is parsed as

      a f (w←1 2 3)

whereas within a dfn it's as

      (a f w)←1 2 3

with the parenthesised part being entirely in the "name" domain.

[paulmansour]

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.

[Phil Last]

Sorry to argue with you Paul, but it's not in the dfn that the difference appears.

      a b c←0 1 2

was 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