Dyalog Forums

Is association of a variable with a file allowed in a dfn? When I use dyadic ⎕XT in a dfn, the association seems to work (control through monadic ⎕XT). When a value is assigned to this variable the asociation appears to get lost. Thereafter monadic ⎕XT returns an empty vector. What is the matter?

Aside, writing on a file is a kind of side effect, it therefore doesn't belong to a proper dfns.

Hi dyallaz,

I have read your post and I think this is what you are seeing.

When you define a name within a dfn, it only exists while the dfn is active. You could use namespace notation to have a variable survive after the dfn has finished...but I do not think this would be recommended practice.

We do not prohibit ⎕XT or file operations within dfns. We leave it to the user to choose how they want to use dfns.

e.g.

{a←3+⍵ ⋄ ⎕←a} 1
4
      a
VALUE ERROR: Undefined name: a
      a
      ∧

           {#.a←3+⍵ ⋄ ⎕←#.a} 1
4
      #.a
4

Regards,

Vince

Thanks Vince for your answer!
I would be quite happy if I could face the interpreter behaviour you are describing. Some precisions to begin with: I use DyalogAPL version 18.2.45505 on a Mac mini M1 running macOS Ventura 13.3.
The problem is: the association seems get lost within the dfn where the external variable is defined. I expected to loose the association after exit from said dfn. As I understand, the value should stay in the associated file which it can be recovered from by a new association, in another dfn. Am I wrong? I need this procedure to provisionally store bulky intermediary results that should lead to a manageable final result.
The function trying to associate:

AssociationTest←{⍺←data
[1]   x←3 ⎕NDELETE d←⍺,'I3D/'
[2]   x←3 ⎕MKDIR d
[3]   x←(d,'x_1s')⎕XT'x_1s'
[4]   ⎕←⎕XT'x_1s'
[5]   x_1s←⍵
[6]   ⎕←⎕XT'x_1s'
[7]   ⍴∊x_1s
[8]   ⍝ Home ws: ASSOCIATION.
[9]   }

The association works at first, it dispears after asignement as following session extract shows:

AssociationTest w
/Volumes/Macintosh HD/Users/andrew/DyalogAPL/data/I3D/x_1s

AssociationTest[5]

AssociationTest[7]
22422

I expected a similar output from line [6] as from line [4]. Stops are set on [5] and [7]. Trying to recover the stored value from the corresponding file drives me to despair. If you are interested, I can provide some evidence about the reason why.
w is defined as

w←222⍴⊂⍳101

.

To quote Lenin: What shall we do?

dfns assigments are effectively (shadow then assign) so you are not assigning to the external variable but rather assigning to a "new" local variable. I spoke about this in one of my fireside chats but I can't remember which one and am about to board a plane
..

Lenin wrote:What shall we do?

I would avoid doing "procedural" programming using dfns. Although you will often get away with it, you are using the technology in ways that the creator did not envisage. A good place to start to gain more insight into the thinking that led to dfns is How to Write Computer Programs by John Scholes.

To expand a little on what has previously been said ...

dfns implement Static Single Assignment (SSA) - every time a value is named using ← the name automatically shadows any previous value. Thus in this example:

⎕cr 'ros'
 ros←{  
     a←1
     a←2
     a  
 }      
      ros 0
2
      a
VALUE ERROR: Undefined name: a
      a
      ∧

the first assignment (a←1) shadows any previous a (there wasn't one), the second assignment shadows the first and then at the end of the function both instances of a are unshadowed, so it reverts to having no value.

Dyadic ⎕XT associates a name with the value within an external variable file, which does not easily fit into the dfn model. One important behavioural consideration is that the name is not automatically localised, which I can't decide is the right or wrong behaviour:

)vars
      ⎕cr 'ros2'
 ros2←{            
     f←(739⌶0),'/x'
     _←f ⎕XT'a'    
     ⎕←⎕XT'a'      
 }                 
      ros2 0
C:\Users\richard\AppData\Local\Temp\x.DXV
      )vars
a
      ⎕EX 'a'

However, whether it shadowed the previous value or not, SSA prevents you from updating the external variable - the normal dfn rules apply: the previous value is automatically shadowed and you assign the value to a different instance of the name, one that is not associated with the external variable:

⎕cr 'ros3'
 ros3←{                                         
     f←(739⌶0),'/x'                             
     _←f ⎕XT'a'                                 
     ⎕←⎕XT'a'                                   
     a←1 ⍝ a "new" a not associated with the external variable
     ⎕←⎕XT'a' ⍝ no name shown; not associated with the external variable
 }

This is awkward. If you are using dfns for their functional characteristics, external variables don't really fit. If you are using them as convenient inline functions, you probably want a way of preventing the automatic localisation. There are ways of doing it, but those of a purist nature may prefer to look away.

Technique 1:

_←⍎'a←1'

Technique 2:

a∘←2

Technique 3:

⎕THIS.a←3