Technical Editorial: in Search of Contexts

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 106

The Workspace is one of the great joys of APL, and it has served us remarkably well from the early days of 28K, through the VSPC days, when we had a whole 120K (or maybe 450K if we pleaded) to romp in, through to today’s multi-megabyte machines. It gives you the freedom to call things by any name you choose, and to assemble a handy collection of working tools in one convenient place, where you know where they all are, and where no-one can change them under your nose.

For the sake of this freedom, we have forced ourselves to adopt a whole set of annoying conventions, or have risked losing vital functions and data with a single misguided )COPY. Typically we name our utilities with unnecessary prefixes (like my own FSM∆this, DRAW∆that set from AP126 days), or just hope that our names are sufficiently improbable that no-one else will have chosen any of them (the APL Statistics Library approach).

This approach was just about tenable when workspace sizes kept us down to a reasonable working set of functions; typically an application was made up of several workspaces, maybe one or more to maintain the base data, one to do the clever stuff (like building a production schedule), one to do the reports, and one to manage the import/export to mainstream systems. On the front of all this would be a tiny MENU workspace to switch between them. If an application broke, almost anyone could hack their way through to the point of failure with a quick check of )FNS and a look at the ⎕LX.

Consider what happens as the workspace size increases, not by the odd factor of two or three, but by an order of magnitude. The universe of names may be large, but the odds of a clash shorten dramatically in a world where there are 10 times as many names!

Consider how you would react when faced with someone else’s broken system where you type )FNS and the listing goes on for page after page after page. 90% of that stuff is ancient, rock-solid utility code — you want to see the 10% that makes this application what it is. It probably fits on 4 or 5 lines.

Consider the awful possibility that there really is a bug deep in the core of that ancient utility code! There may be hundreds of workspaces out there, all falling over just because Easter is in March this year. Mainframe folk know well enough the necessity of infecting each and every workspace with a little piece of virus code that will go and check its utility timestamps against some central library, and automatically upgrade everyone with the latest versions of everything. But hang on a minute … this is my application, running in my workspace! I don’t want it falling over just because some cretin in the back office has ‘fixed’ a utility with the latest whizzo assembler code. I want to check it all out first, then ship that upgrade when I know it works. Anyway, viruses have got rather a bad name of late.

Under Windows, things get a whole lot worse. You have to program with a raft of small functions, because you have lots of objects out there, and the user may interact with any of them at any time in many different ways. Each combination of object/event usually needs a function to handle it, often a one-liner. Many objects really need little functions of their own, ranging from a simple upper-case mapper (for a text entry field), through date conversion (a date box), to a significant subset of PostScript (the RAIN graphics viewer).

Now, I want to call the APL function that does the PostScript ‘moveto’ operation moveto, and similarly for lineto, show, currentpoint, and so on. These are not particularly improbable names, and I can’t imagine anyone would use my workspace more than once if they did a )COPY RAIN and their show function was promptly obliterated!

To a limited extent, clever progammers have found ways of fudging round the problem. APL*PLUS/PC does some amazing things with local ⎕FX to implement ]UCMD, and with Dyalog you can do a bit of fancy footwork with ⎕SHADOW and ⎕OR. This is how Duncan & I implement local variables on forms — we just stick them in the object’s DATA property, and shadow and execute them when required. Yes, it works, but it is a monumental kludge we would be better off without.

What we need to do now …¶

J has "locales", Manugistics have promised us "capsules", Dyadic are working on "namespaces" and APL2 has ⎕NA. Please let them all know that we need this stuff, and that we need them to get it right. It must take away for ever the need for pointless prefixes on function names, it must offer us a sensible way of managing utility upgrades, and it must above all cut )FNS down to something that fits easily on one screen. If it does all that, and includes the Windows objects in a tolerably consistent way, then I, for one, will be a lot happier about the future of APL.