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
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
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) ...
XCFC 1 6
XCLX 1 27 'Weather records - APLX
FAcquire FX 'z½folder Acquire file;IO;tie;date' 'ä Acquire
data for a ø
given date' 'IO½0' 'date½file' '((date=''-'')/date)½'' '''
date' 'z½ReadNativeFile folder,file,''.txt''' 'z½Parse z'
Sun((Æþz)îSUNLIST)/z' 'date AcquireCity((Æþz)îCITYLIST)/z'
FAcquireSun FX 'date AcquireSun values;IO;col' 'ä Add
values to <SunData> global' 'IO½0' ':If
o date' ' :If ~colîìæDAYLIST'
' Extend DayNo date'
ìDayNo date' ' :EndIf' '
unrise'')/values' ' SUNDATA[1;col]½''''æfi
X')/values' ':Else' ' ø'
.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
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
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
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
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
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
It's less popular, but you can read
about some experiments if you like.
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...
⍝ Drop all blanks
⎕ML←3 ⋄ ⍺←' ' ⋄
⍝ Drop Ending Blanks
⍺←' ' ⋄
∇,[¯1↓⍳⍴⍴⍵]⍵ ⍝ array
Building workspaces from script files is straightforward.
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
Page created 22 October
2008; Copyright © Dogon Research 2008