Dear Jürgen, Thank you for your response. Implementing 11⎕CR and 12⎕CR would be very helpful.
I still need an answer to question 3 if you can. Thanks! Blake On Sat, Apr 19, 2014 at 8:05 AM, Juergen Sauermann < [email protected]> wrote: > 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 >> >> >
