Workspaces and so forth...

Every so often there's a flurry of discussion at places like comp.lang.apl about workspaces, how to move code between versions of APL, and how to store code.

Frequently fragmenting and spewing off-topic, with misinformation freely thrown into the mix - both innocently and deliberately.

Herewith a personal summary of workspaces and related matters as of late 2008.

Workspaces

The concept of the workspace is fundamental to APL, it's what we interact with as we run an APL session.  You could say it makes APL what it is.

At heart the workspace is an unstructured collection of data variables, functions and operators - which we might think of as a purpose-driven enrichment of APL to deal with a specific computing requirement.

The contents of the workspace may require a human to drive them together (the "inquisitive programming" model), or be arranged through a calling structure into a packageable application.

Clearly we don't expect computers to just sit "running stuff" perpetually, and so APL has always (or almost always) offered the option of saving a workspace to file "as is" (well, while it's sitting dormant waiting for user activity) and loading from file.  The model elaborates a little, because we can also copy bits and pieces from other saved workspaces and integrate them into our active workspace (sending bits of the active workspace out and putting them into saved workspaces needs a little more effort - it's not done very much).

Workspace Transfer

And for simple requirements, that's good enough.  The mechanism is good enough to let us share workspaces with other APL users on compatible machines.

But there are more complex needs, one of these being to transfer APL workspaces onto different hardware and/or APL from another supplier (workspaces are a proprietary binary format).  Two workspace interchange or transfer standards (using the term loosely) were developed in the past

Workspace Interchange (WSIS0)

The WSIS0 scheme had a utopian goal - to allow people to move APL code freely across hardware and software boundaries.  It was current in the 1980s, worked adequately for first-generation APLs (before nested arrays), but seems to have falen by the wayside.

APL Transfer Form

APL Transfer form is something of an IBM-generated tool, although it has been adopted to some degree by other vendors.  Both the earlier VSAPL and the current APL2 products from IBM offered the option of saving workspaces as .ATF files as an alternative to saving the workspace "as a workspace" - both could also recreate a workspace from a .ATF file.

The .ATF file format is a linearisation of workspace contents, broken down into 80-column records - you could (if you wanted) get your IBM mainframe to physically make a punched card representation of a workspace.  Here's the start of a .ATF file (it doesn't look quite right because of font differences) ...

XNPP 0 10                                                                    
XNIO 0 0                                                                     
XNCT 0 1E13                                                                 
XCFC 1 6 .,*0_                                                              
XNRL 0 16807                                                                 
XCPR 1 1                                                                     
XCLX 1 27 'Weather records - APLX V2'                                        
 FAcquire FX 'zfolder Acquire file;IO;tie;date' ' Acquire data for a      
  given date' 'IO0' 'datefile' '((date=''-'')/date)'' ''' 'datefi       
 date' 'zReadNativeFile folder,file,''.txt''' 'zParse z' 'date Acquire      
 Sun((z)SUNLIST)/z' 'date AcquireCity((z)CITYLIST)/z' 'WriteGlobal      
XData WorkingFolder '''''                                                     
 FAcquireSun FX 'date AcquireSun values;IO;col' ' Add sunrise/sunset       
 values to <SunData> global' 'IO0' ':If 2=values' '  colDAYLISTDayN      
 o date' '  :If ~colDAYLIST' '    Extend DayNo date' '    colDAYLIST      
 DayNo date' '  :EndIf' '  SUNDATA[0;col]''''fi 1,((values)''S      
 unrise'')/values' '  SUNDATA[1;col]''''fi 1,((values)''Sunset'      
X')/values' ':Else' '  ' ':EndIf'                                    

.ATF files tended to be rather smaller than .APL files (the filename extension used by IBM for directly saved workspaces), and were relativly popular.  To my recollection (which may be wrong) .ATF files could hold representations of nested arrays.

Most current versions of APL can read .ATF files and construct an active workspace, either directly (APLX, for example), or by using code written for the purpose (Dyalog handles .ATF files this way).  Some can write .ATF files (APLX again), while others leave this as an exercise for the Reader (Dyalog, I believe).

So long as vendor-specific code is avoided the .ATF file format is a reasonable solution to the problem of moving APL code from one version of APL to another (of course, it isn't needed if you want to move your code to a newer and greater release of the APL version you already have).

But APL Transfer Form only moves the code, it doesn't move the meaning (so, if you use language features specific to APL2 which aren't availavble as part of Dyalog APL - for example - you still need to do some manual conversion to make the code work fully).  APL Transfer Form is also rooted in the days of "flat" workspaces, and doesn't readily cater for the structured workspaces typical of present-day Dyalog.  As usual, only the lowest common denominator wins.

Workspaces and Application Packages

People using APL to develop application packages to be used by third parties (who don't need to know that APL is involved) start to generate their own requirements for code storage and active workspace generation (remember - APL always has a workspace - even if it's not stored explicitly on file).

The first thing that happens is that the data is separated out and stored on file (or database, or whatever) - all that's in the workspace is code - functions and operators.  There may be some need for configuration data - setting the workspace into a suitable state, but that's data.

We could meet the packaging requirement by just saving and loading workspaces - regard them as a strange type of executable file (indeed some APLs have facilities to save workspaces as .EXE files).  In some cases that's enough.

Storing Code on File

However, application development groups larger than the proverbial one-man-garage want to address further requirements.  They may have multiple applications, library code to share between developers and so forth.  There's also some historic baggage in so far as a complex application might require more code than the available hardware could handle - although that's less of a problem these days.  Various approaches have been taken to move code "out of the workspace" - some are historic, some are being defined and refined currently.

Function Files

This is the traditionalist approach - canonical representations stored as components in one or more component files (possibly with one function/operator/variable per component, more likely with collections grouped into the components).

Go into any large-scale APL development shop and this is what you're likely to find - with a whole heap of home-grown tools for version control and so forth.

It works - has done for years - and the only real pitfall is that everybody who has made one has done it differently, there's no "industry standardisation" (one or more developer might be kept busy fulltime maintaining the development tools).  And come the day that the code has to be ported to a different vendor's APL there may be mayhem.

Code Databases

A variation on the traditional function file, this time the code is held within a relational database.  Which usually leads to added sophistication with specification and test cases bundled in with the code.

It's less popular, but you can read about some experiments if you like.

Scripts

Scripts are the "coming thing" as of 2008, combined with adoption of Unicode they offer significant easing of the code portablity question (not only can code be cut and pasted between versions of APL, code on file can be read - meaningfully and simply - by different APLs).

A script is a linearisation of function/operator definitions (variables don't really "fit", and are largely either constructed on-the-fly or held on file), typically several (hopefully related) together in each script, here's an example...

   
      dab←{                                          ⍝ Drop all blanks
          ⎕ML←3 ⋄ ⍺←' ' ⋄ 1<≡⍵:(⊂⍺)∇⍵               ⍝ nested?
          1≥⍴⍴⍵:⍵~⍺                                  ⍝ vector
          2=⍴⍴⍵:⊃(↓⍵)~⊂⍺                            ⍝ matrix
          (1↓⍴⍵){(⍺,1↓⍴⍵)⍴⍵}⍺ ∇,[1↓⍳⍴⍴⍵]⍵          ⍝ array
      }
      deb←{                                          ⍝ Drop Ending Blanks
          ⍺←' ' ⋄ 1<|≡⍵:(⊂⍺)∇⍵                      ⍝ nested?
          2<⍴⍴⍵:(1↓⍴⍵){(⍺,1↓⍴⍵)⍴⍵}⍺ ∇,[1↓⍳⍴⍴⍵]⍵    ⍝ array
          b←⍵∊⍺                                      ⍝ mask
          1≥⍴⍴⍵:((∧\b)⍱⌽∧\⌽b)/⍵                      ⍝ vector
          b←∧⌿b ⋄ ((∧\b)⍱⌽∧\⌽b)/⍵                    ⍝ matrix
      }

Building workspaces from script files is straightforward.

An advantage of scripts is that since they are "just" Unicode files they can be dropped into "industry standard" code management tools (the "APL isn't special any more" argument again, in a different context).  But, on the other hand, APL veterans find the linearisation awkward and it remains to be seen how the vendors will develop the APL IDE to more comfortably combine scripts with the dynamic of APL development.


Page created 22 October 2008; Copyright Dogon Research 2008