External variables in dfns

A forum for issues on macOS; the UNIX and Linux forums may have relevent posts

External variables in dfns

Postby dyallaz on Tue Apr 11, 2023 1:46 pm

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

Re: External variables in dfns

Postby Vince|Dyalog on Wed Apr 12, 2023 9:38 am

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
Vince|Dyalog
 
Posts: 443
Joined: Wed Oct 01, 2008 9:39 am

Re: External variables in dfns

Postby dyallaz on Fri Apr 14, 2023 9:22 pm

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?
dyallaz
 

Re: External variables in dfns

Postby AndyS|Dyalog on Sat Apr 15, 2023 8:00 am

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
..
User avatar
AndyS|Dyalog
 
Posts: 263
Joined: Tue May 12, 2009 6:06 pm

Re: External variables in dfns

Postby Morten|Dyalog on Sat Apr 15, 2023 10:20 am

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.
User avatar
Morten|Dyalog
 
Posts: 462
Joined: Tue Sep 09, 2008 3:52 pm

Re: External variables in dfns

Postby Richard|Dyalog on Wed Apr 19, 2023 12:47 pm

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
User avatar
Richard|Dyalog
 
Posts: 44
Joined: Thu Oct 02, 2008 11:11 am

Re: External variables in dfns

Postby kai on Wed Apr 19, 2023 7:57 pm

Technique 3:

      ⎕THIS.a←3
User avatar
kai
 
Posts: 141
Joined: Thu Jun 18, 2009 5:10 pm
Location: Hillesheim / Germany


Return to macOS

Who is online

Users browsing this forum: No registered users and 0 guests