Re: [Bug-apl] Questions about GNU APL

[Juergen Sauermann]

Hi,

just as an add-on to Nick'comments:

There are several ⎕-functions in GNU APL that translate between internal
APL values and variables and byte vectors that can be stored externally,
eg. via the FILE_IO native function (that provides several standard libc 
functions
like fread(), fwrite(), etc.):

* ⎕TF and 2⎕TF as known from IBM APL2,

* 3 ⎕TF which is similar to 2 ⎕TF but produces IBM's CDR (common data 
representation) format.
This format is used between GNU APL and its shared variables/APs. No 
restrictions for nesting.

* 10 ⎕CR which similar to 2⎕TF in that it generates an executable APL 
expression that can be executes
in order to reproduce a variable with a value. Unlike 2 ⎕TF it produces 
a UTF-8 encoded string rather
than a character vector in IBM's ⎕AV. ALso no restrictions for nesting. 
Use like this:

X←((1 2 3) 4 5) 'abc' 'd'
EX←10 ⎕CR 'X'
EX
X←3⍴0 X[0+⍳3]←'∘∘d' ((⎕IO+0)⊃X)←⊂3⍴0 ((⎕IO+0)⊃X)[0+⍳3]←'∘',4,5 ((⎕IO+0 
0)⊃X)←3⍴
1,2,3 ((⎕IO+1)⊃X)←3⍴'abc'
)ERASE X
X
VALUE ERROR
X
^
⍎¨EX
0 0 0 ∘∘d 0 0 0 ∘ 4 5 1 2 3 abc
X
1 2 3 4 5 abc d


/// Jürgen


On 04/01/2014 06:05 PM, Nick Lobachevsky wrote:
> 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.