Re: [Bug-apl] Towards a keyed and component file system

[Juergen Sauermann]

Hi Blake,

3 ⎕TF produces a byte vector in the CDR (common data representation) 
format defined by IBM.
It was a by-product  of the CDR format which is used internally in GNU 
APL for communication
with shared variables and other running GNU APL workspaces. Right now 
there is no inverse
function for 3 ⎕TF at APL level even though CDR decoding end encoding is 
implemented
(with the exception of the "progression" type that does not occur in GNU 
APL).

I could add these functions but I would use dyadic ⎕CR rather than ⎕TF 
because that lets you
work with the values rather than variable names. That is, instead of 
"var←value ◊ 3 ⎕TF 'var'"
you could do eg. "11⎕CR value" directly and 12⎕CR to convert back.

There is also a similar format called "SCAR" which seems to be supported 
by other APL interpreters
for exchanging data. I am looking forward to implement that as well, but 
I am currently lacking
some more information about it.

/// Jürgen


On 04/19/2014 12:16 PM, Blake McBride wrote:
> Greetings,
>
> Now that the wonderful SQL interface is working for me, I believe I 
> can create a component and keyed file system in straight APL easily. 
>  I just need to understand ⎕TF a bit better.
>
> 1.  3 ⎕TF seems to produce a string vector representation of an 
> arbitrary nested array without retaining the specific name of the 
> variable.  Is this true?  (If so, this is exactly what I need!)
>
> 2.  How can I reverse the process?  i.e. if X holds the result of a 3 
> ⎕TF, I need a way of converting it back to an APL (possibly nested) 
> array that is exactly the same array.  i.e.:
>
> x←(5 5⍴⍳25) 'Hello there'
> y←3⎕TF'x'
> z←??????????
>
> I need to know what ?????? is so that x and z have the exactly 
> equivalent arrays.
>
> 3.  I am a little concerned that the vector produced by 3 ⎕TF may have 
> trouble going to and from an SQL VARCHAR using the existing (and 
> fantastic!) library.  I am not sure, but there may be a problem with C 
> null characters ('\0') or other non-printable characters.  Some 
> feedback on this would be very helpful.
>
> I suppose I can achieve the same effect by using 2⎕TF and then 
> dropping the assignment part before executing the string.  This should 
> be highly portable but I'd guess less efficient.  Thoughts?
>
> Thanks a lot!!
>
> Blake