Code Interchange

Dick Bowman
20 November 2007

One of the ongoing joys of APL is that several vendors are actively developing their own products.  The promiscuous (or wary) APL user is therefore interested in being able to move code from one APL version to another.

There's always a problem with this vendor-agnostic attitude - that code needs to be restricted to the common denominator of the various versions.  How serious this is as a limitation is a decision for the application coder.

One longstanding interchange vehicle has been the .ATF (APL Transfer Form) file format - originally introduced by IBM and for which there are read/write utilities for most (if not all) vendor-specific APL products.

Over the past 18 months Dyalog has been heading in a direction of  storing APL code in a "scriptish" form where it may be read, written and edited using "industry-standard" tools (including version control software) outside of the APL environment.  As to whether abandoning a tightly-integrated IDE in favour of a decoupled edit-run-reedit-rerun model is a good idea, I offer no comment here.  This is a by-product of Dyalog Version 11 object-orientation extensions and Unicode support.

The most recent (Version 4) APLX introduces a similar approach to object-orientation and a similar ability to hold code within classes.

A natural question therefore is whether there's a new way to move (or share) code between APLX and Dyalog.  Having a common (shared and automatically-synchronised) utility library appeals.

Reading Dyalog Namespace Scripts into APLX.

My currently-experimental code to do this is embarassingly clumsy - suffice to say that it all happens in a couple of dozen lines and can be used with statements like

'fromdyalog' ReadDogalog 'c:\dick\mycode\dyalog\file.dogalog'

which creates a class called <fromdyalog> from the file (these files are created using Dyalog's UnicodeFile class - just like their SALT stuff, except that I use my own filename extension to keep my scripts distinct from Dyalog's)

Things that break - or aren't yet handled...
But - a lot of code can make the transition.   It may well need further editing before it's useful in APLX applications.

Reading APLX Classes into Dyalog Namespace Scripts.

Export from APLX to a "scriptish" Unicode file is embarassingly simple...

(⎕cr 'howdy')⎕export 'c:\dick\temp\aplx.dogalog' 'utf-16'

Whence it can be read using Dyalog's UnicodeFile class (or more simply with newer Version 11.1 features).

Strip out the head/tail and fix the functions.

Code compatibility in this direction is a little less of an issue (not much that stops functions and operators being fixed, you may need to manually tweak to put braces round optional results and left arguments).

Conclusions

The text above is (deliberately) a bit sketchy - at this time I don't have a need to move code between these versions of APL.  The principle is established - code can do a round trip through the "other" interpreter and arrive back in an executable form.

But what's clear is that - despite the detail syntax being different - Dyalog and APLX with their object-oriented extensions have opened up a new possibility in terms of sharing code between users of different versions of APL.

If you want to interchange code this way, the requirement to adapt to a lowest-common-denominator coding style remains - although it is surely possible to add some (fairly mechanical) syntax-tweakery to the export/import mechanisms.

But we're moving ahead - even though too close an obsession with detail might suggest we are not.

This doen't replace existing methods of code interchange - but it does add something new.

Copyright Dogon Research, 2006-2007.  Material from the Dogon Research Music and APL Pages may be freely redistributed, but copyright is retained and attribution to Dogon Research is requested.