Function Files

This topic is specifically for discussions on the new APL64 Project currently in development. This topic is open for all to browse. However, to post, one must have a registered account on the APLDN forum only available to APL+Win licensee under a current APL+Win Subscription.

Moderators: Tech Support, phpbb_admin

Function Files

Postby Eric.Lescasse » October 12th, 2018, 12:59 pm

Almost all the APL developers I work with are bringing APL functions from file in their workspace and this for many reasons (not clutter the workspace, share the utilities among many workspaces, avoid the same function to exist in several workspaces with slightly different versions, etc.)

Since there is no system built in APL+Win for doing that (I mean no appropriate set of [] functions for doing the job), they've mostly all developed more or less the same mechanism, but all with defects.
This seems to clearly indicate that there is a big need for such a system in the language.

The thing which would be great would be if the [] function that would fetch an APL function from file, could recursively find the subroutines called by this function and automatically fetch them from file as well (at least all the ones which are not called thru the execute primitive).

Have you thought about building such a system in APL64?
Eric.Lescasse
 
Posts: 52
Joined: February 8th, 2007, 7:55 pm
Location: Paris, France

Re: Function Files

Postby Davin Church » October 12th, 2018, 1:59 pm

I know there's a lot of history in function files, but I haven't used them for decades. My primary reason (and I assume many others) was to keep the workspace size down to something that can be )LOADed. With workspace sizes now measured in gigabytes (and soon to be exabytes), that reason has really gone away. I'm sure there are old applications that still do this that you want to maintain, but I can't see anyone changing the way they do this just because there's a new feature available.

You also mentioned other reasons to have function files, but I don't see that any of them can't be reasonably fixed in other (programmable) ways. For instance, if you're worried about FF code that doesn't do the job well, then pick a tool that works (without defects) and use it. I have a set of tools that I called my "cf" utilities, for instance, that I think does a great job of handling named component files which are ideal for FF storage (which mostly uses only a single standalone function, so as not to clutter the workspace itself). But anyone that puts together a nice system can distribute it and everyone's problem is solved.

For keeping utilities synchronized, normal APL processes should be sufficient without invoking new languages features, and it wouldn't even be necessary to use function files. For one example (and others are feasible), several years ago I wrote a system called ARM (see recent public distribution in http://forum.apl2000.com/viewtopic.php?f=7&t=1209) that helps you manage application code. It includes a "toolkit" facility where updated tools are automatically distributed to all the applications that use them. I've been using nothing but that for nearly 7 years now and find it to be a wonderful solution to this problem, but anyone can write their own auto-distribution tool if they have a mind to. ARM, BTW, should be able to run in APL64 with no or trivial adjustments.

As for cluttering the workspace, I don't see much of a problem with that. Very many times I want to use my utilities from the session and surely don't want to have to fetch them first (or else I'd use )COPY). My utilities (which may be an exception) rarely have subroutines, and APL64 will generally get rid of that need anyway with :DEF. I also use more utilites, more often, than anyone else I've seen, so I'm probably an extreme case.
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Re: Function Files

Postby Ajay Askoolum » October 14th, 2018, 3:29 am

The improvements to function--component--files that would really matter would be:

a. the facility to refer to components by name rather than number
b. the ability to list all the names in the component file.

)group disappeared from the workspace a while back. Had it existed, it would have been nice to be able to save groups by name to component files, might even preserve definition timestamps.
Ajay Askoolum
 
Posts: 884
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom

Re: Function Files

Postby Davin Church » October 14th, 2018, 2:32 pm

Ajay Askoolum wrote:a. the facility to refer to components by name rather than number

Try out my named-component tools at http://forum.apl2000.com/viewtopic.php?f=7&t=1215 and see if they do the kinds of things you have in mind.

These should be usable directly in APL64, but including them as ⎕CF... system fns might also be possible.
Ajay Askoolum wrote:b. the ability to list all the names in the component file.

While important at a minimum, I think you might need more kinds of "directory" features in a complete system. See my "cfDir" function in the above workspace for some examples of other things you might want to have.
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Re: Function Files

Postby Eric.Lescasse » October 14th, 2018, 3:43 pm

Just FYI: it is perfectly possible to save groups of functions (and/or variables) to component files, more exactly to User Commands component files.

All you have to do is:

Code: Select all
      mygroup←'fnname1 fnname2 ... fnnameN'
      ]usave .mygroup


Then, to load all objects contained in the group, into the current workspace:

Code: Select all
      ]uload .mygroup /r


To list all elements contained in the group:

Code: Select all
      ]uread mygroup


And of course you can use other User Commands to maintain the group as need be.
Eric.Lescasse
 
Posts: 52
Joined: February 8th, 2007, 7:55 pm
Location: Paris, France

Re: Function Files

Postby Davin Church » October 14th, 2018, 5:00 pm

Yes, I agree - many APL filing utilities can handle "groups" in one way or another.

Should I write a simple function-file-with-groups handler for my cf* tools as an example?
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Re: Function Files

Postby Garth Hutchinson » October 14th, 2018, 10:20 pm

Ever written that perfect little functions, then used it across countless workspaces? Two years later you discover that there is one rare sitution you missed. That's why dynamic loading of functions is useful, and used something like ]UCMD or Davin's named component files (q.v) -- and everyone else has invented something. But this, libraries, packages all show great potential for even greater RAD.
R. Garth Hutchinson, BTh, FCIA
In systems since 1962, APL-er since 1970's
Garth Hutchinson
 
Posts: 45
Joined: September 24th, 2008, 9:24 am
Location: Aurora, Ontario, Canada

Re: Function Files

Postby Davin Church » October 14th, 2018, 10:54 pm

Garth Hutchinson wrote:Ever written that perfect little functions, then used it across countless workspaces?

Sure - I've got dozens of such beasts, and occasionally improve even the ones that I've been using for decades. But nowadays I've been keep my toolkit synchronized using my ARM library system, and that seems to do everything I really need to keep things up to date. There are reasons (even personal ones) that it got all the features that it did, including this one.
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am


Return to APL64 Project

Who is online

Users browsing this forum: No registered users and 4 guests

cron