APLDN Forum

Please allow 0 as the right-hand argument of file tie functions such that the functions return

- 0⍴0 if the file is already tied
- 0 if the file does not exist
- the tie number of the file (which will be the next available tie number), negative for native files and positive for component files, if the file exists and is not already tied

This:
- will minimize user code to handle the various scenarios when tieing a file
- might be a useful funtionality to include with APL64 also.

Ajay Askoolum wrote:- 0⍴0 if the file is already tied

Keep in mind that this cannot be reliably detected, due to the vagaries that are possible when the OS provides access to a given file using multiple names.

Also, in my applications, if a file is already tied then I'd want to see what number it's tied to (so I can use it). One of my utility functions does this (as best it can) by returning a negative tie number that I can detect and process easily.

...due to the vagaries that are possible when the OS provides access to a given file using multiple names.

I am not sure that I understand this; perhaps you can elaborate?

Also, in my applications, if a file is already tied then I'd want to see what number it's tied to (so I can use it)

That was going to be my suggestion but I realized that, for native files, if I have lost track of the tie number in the current context I would have no idea at which byte the read head is and there is no way to query this problematically. Moreover, if I've lost track of the (existing) tie number it is highly likely that I've lost track of the variable holding any index that I might have built for the file. In other words, if using the existing tie number, I would have no way of determining the fourth argument of []nread; hence the preference for 0⍴0 so that I can re-tie the file (read figure out why the file was tied in a context where I need to use the file and tidy up my code).

That said, I know that I can use the existing number and start afresh by executing

Code: Select all

⎕nread tie 82 0 0

Therefore there is some merit in your suggestion; thanks.

Ajay Askoolum wrote:

...due to the vagaries that are possible when the OS provides access to a given file using multiple names.

I am not sure that I understand this; perhaps you can elaborate?

There are many possibilities, but think about a simple one: Let's say you've tied a file to F:\ABC\xyz.sf, where the F: drive is mapped to a network machine named NNNN. That file can also be referenced with a UNC path by \\NNN\C\ABC\xyz.sf. This equivalence is not easy to detect.

Ajay Askoolum wrote:That was going to be my suggestion but I realized that, for native files, if I have lost track of the tie number in the current context I would have no idea at which byte the read head is and there is no way to query this problematically. Moreover, if I've lost track of the (existing) tie number it is highly likely that I've lost track of the variable holding any index that I might have built for the file. In other words, if using the existing tie number, I would have no way of determining the fourth argument of []nread; hence the preference for 0⍴0 so that I can re-tie the file (read figure out why the file was tied in a context where I need to use the file and tidy up my code).

I seldom need such features for native files, but you can always reset the file pointer as mentioned.

Also, none of this is a matter (for me) of "losing track of the tie number". The issue that I have trouble with is when I have a routine to access a file independently, typically by tying and untying it at the beginning and end of the function. But I don't know (and sometimes can't tell) if the file is already tied by some other program in the stack, nor to what tie number the other program has tied it. So I'd like to be able to use the existing tie (and not untie it afterwards) because I can't create a duplicate tie to the file.

Also, you can detect a negative tie number (or positive, in the case of a native file) just as easily as an empty vector. The value can be ignored if you don't need it.