Re: An APL Archive

Morten Kromberg wrote:

As far as the format of an archive is concerned, I think UNICODE has
become the right format to use. It contains all the symbols used by
past and present APL systems, and allows us to put APL code into files
which most computer systems are starting to treat as "simple text
files".
Dyalog aims to support loading from and saving APL code in Unicode
files in the very near future. To be precise, the format we intend to
support is (if I got this right) UCS-2, which is a relatively simple
file format in which the first two bytes of the file are FFFE or FEFF
depending on whether the file is big- or little-endian, followed by two
bytes for each UNICODE character.

I agree with Morten on this. Unicode is the way to go since it is
vendor-neutral, supported by non-APL applications, and even allows APL
code to be displayed tolerably well in generally-available fonts from
Microsoft and others. In particular, I agree with Morten that we
should standarize on the 2-byte UTF-16 representation, because it is
easy to deal with and is used directly by the Windows programming
interfaces.

APLX, and I believe all the other major APLs, already support data
exchange using Unicode. Even if a particular APL does not have
built-in Unicode support, it is trivial to translate back and forth
between UTF-16 and the Quad-AV of any given APL system.


There may still be a need for an additional format to describe DATA,
but again there are already suitable formats for this based on XML, in
the public domain.


Absolutely right. I would like to propose that the APL vendors get
together to agree on a standard XML scheme for describing APL 'things'
(I would use the word 'objects', but that has too specific a meaning
here.) As a start, this should encompass simple and nested arrays,
user-defined functions, and workspaces which contain only the above.
'Things' of this kind should be pretty well portable amongst at least
APL2, APLX, Dyalog and APL+Win, and to a certain extent Sharp APL as
well. Extensions to this base scheme could be agreed for user-defined
operators (which should be portable between APL2, APLX and Dyalog, but
I believe are not supported by APL+Win). Dyalog has a number of
further language extensions (D-fns, namespaces, and now objects) which
would not currently be portable across APL interpreters, but if we
agree on a sensible XML scheme it might be possible in the future to
provide some portability here too.

It would also be easy to extend the XML scheme to represent component
files (it would be a rather verbose representation, but who cares -
storage is cheap nowadays).

Any takers?

Richard Nabavi
MicroAPL Ltd

.

Relevant Pages

  • Re: An APL Archive
    ... As far as the format of an archive is concerned, I think UNICODE has ... past and present APL systems, and allows us to put APL code into files ... Dyalog have an "Input Mode Editor" application, ...
    (comp.lang.apl)
  • Re: Test of Unicode APL characters with Mozilla
    ... At Jsoftware.com they have done a great job with Unicode support in J ... Unicode will not just open up support for APL of course ... >> Mozilla Firefox 1.0.6 has excelent support for Unicode ...
    (comp.lang.apl)
  • Re: An APL Archive
    ... Morten -- are those glitches down to the browsers, ... "Full Unicode ... our goal will be to be as compatible as possible with what other APL ... This format was designed for Insight Systems more than 10 ...
    (comp.lang.apl)
  • Re: Thesaurus Problem
    ... files by using text editor tools, the files must be saved in Unicode format ... RelevantNoise.com - dedicated to mining blogs for business intelligence. ... be saved as a Unicode file. ... FROM FullDocuments ...
    (microsoft.public.sqlserver.fulltext)
  • Re: SBS 2003 Standard/Exchange Server issue
    ... To enforce Unicode mode in Outlook ... load the Outlook 2003 template. ... Double-click Exchange Unicode Mode - Ignore Archive Format. ... Double-click Exchange Unicode Mode - Ignore OST Format. ...
    (microsoft.public.windows.server.sbs)