File ties

General discussions on potential enhancements to the APL+Win system.

File ties

Postby Ajay Askoolum » April 6th, 2020, 3:47 am

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
 
Posts: 842
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom

Re: File ties

Postby Davin Church » April 6th, 2020, 12:33 pm

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.
Davin Church
 
Posts: 633
Joined: February 24th, 2007, 1:46 am

Re: File ties

Postby Ajay Askoolum » April 6th, 2020, 3:39 pm

...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
 
Posts: 842
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom

Re: File ties

Postby Davin Church » April 6th, 2020, 8:12 pm

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.
Davin Church
 
Posts: 633
Joined: February 24th, 2007, 1:46 am


Return to APL+Win Wish-List

Who is online

Users browsing this forum: No registered users and 2 guests

cron