Code InterchangeDick Bowman
20 November 2007
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
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
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
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'
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.
- Dynamic functions (and operators) - not clear whether there's any way of writing a translator.
- Anything that isn't a traditionally-defined function or operator (so no variable assignments etc.)
- Dyalog-specific system variables in function/operator headers (the code just throws these away)
- Dyalog's brace-enclosed optional results and left arguments.
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.
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).
ConclusionsThe 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.
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.