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.
