COMPONENT FILES

[Ajay Askoolum]

My current COVID-19 propelled pastime is to  see if I can write to SQLite, SQL Server & Access what can be written to a component file. So far it looks very encouraging.

- []av survives the round trip APL+Win -> SQLite ->APL+Win

- []dr 82 323 645 807 workspace variables also survive the round trip.

The primary advantages of storing in a database

- named components

- the collation of statistics e.g. datewritten, datemodified, dateaccessed, accesscount etc

- the data or component is interpreter independent.

I have some questions:

1. What is the size of the largest component you've written?

2. Are you able to share  a file with complex components - I will use this for testing.

Do you have any thoughts on this?

[Rex Swain]

If you can store ⎕AV, you are all set -- just use 'wrapl' ⎕dr A and you can store any array.

Most SQLs have a column (maybe called BLOB?) for storing very large character strings.

I don't know about "interpreter independent", because ⎕AV is different across APL interpreters.

Also, I bet SQL performance will be slower than APL component files.  But maybe that does not matter to you.

[Ajay Askoolum]

I am passing the actual value of the workspace variable NOT its 'wrapl' []dr - hence interpreter independent.

I've tried to write data from APLX and read in APL+Win and vice versa with success. []av comes into play when writing []cr of functions - it does/would not work across interpreters.

Still work-in-progress & some issues to address e.g.

a. Literal arrays of depth 1 APL's last dimension is the number of characters whereas in other languages it is 1.

b. Scalar  numeric survives & returns with empty shape but scalar literal returns with shape 1

There may be other issues yet to discover but so far it looks very promising especially when I the round trip of  []vr of functions works.

Not done any timings yet but even if a little slower, the advantage is that data acquisition & transfer is so much easier. in that other applications can read and write the same data.

Yes, its BLOB (SQLite) , IMAGE (SQL Server) LONG TEXT (MS Access). 

[Davin Church]

SQL seems to have no difficulties storing any APL text, but arrays of arbitrary type can't be done unless you have some sort of encoding method (or assumption) that also stores the rank, rho, depth(s) and datatype(s) along with the data.  'wrapl' does this, but of course isn't portable, so you'd have to write your own.  You could also do something like encoding an APL object in XML and that stores just fine.  But data types and ranks are otherwise going to be tough to deal with in a general case.

I've stored APL code and other text in SQL fields plenty of times, but I've never done anything really big.  I think APL file components are limited to maximum interpreter variable size (about 2*31 bytes and elements) and SQL BLOBs can usually run very large in most DBs (2*32 in some, IIRC).

I agree with Rex about speed and []AV. I won't mention other thoughts because they don't qualify for interpreter-portable.