Re: [Bug-apl] Questions about GNU APL

[Nick Lobachevsky]

As for file systems, I did something like this years ago for a client
who (A) refused to have his data tied up in a proprietary format, and
(B) wanted to share data across Dyalog APL and APL2000.  This dates
back to the Windows 8.3 FAT file system days, this could be far better
(or worse) with the right file system.  File locking ([]FHOLD) was not
needed and not implemented.  File access control was implemented with
Novell or whatever the client was using at the time.

- A conceptual APL component file is a Directory.

- File system components are individual physical files named something
where component 42 would be "00000042.ncf",  .ncf stood for "Native
Component File"

- File metadata was stored in Component Zero, i.e. "00000000.ncf"

- []FCREATE was mkdir, []FAPPEND created a new file, []FREPLACE
rewrote the entire file, []FDROP erased individual files, []FERASE
deleted the entire directory, etc.

- []FSIZE info was stored in the metadata component

- Component data was something like this:
(thorn (shape encoded data), ([]DR data), shape data), 82 []DR data

Monadic []DR returned the encoding of the data type, 82 was char, 163
was 16 bit integer, etc.  Dyadic 82 []DR converted the data content to
character.  Character data was always stored translated to Dyalog's
[]AV.  To re-materialise the data, you would split the component from
its header and data and use []DR to bring the data back to its
original type.  Not all data types were available on both systems.  I
did not deal with nested or mixed arrays.

Performance was adequate.

I suppose you can design a database this way.