Packages for APL64

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

Packages for APL64

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

I am wondering if it would be feasible to create the notion of Packages in APL64.

A lot of the success of R and Python comes from the huge amount of already done Libraries or Packages that augment the language and allow a developer to almost do anything he can think of with little efforts.
For example, in R, anyone can load and install any given package among hundreds using the simple: install.packages command and then load the package into memory to use it with the: library command

A lot of us have written nice APL utilities, and there are tons of them out there (developed by Brent Hildebrand, Davin Church, Rex Swain and many others), but they are not centralized in one unique repository, maybe too hard to find for a common APL user, and sometimes they are not documented or not enough documented to be easily usable by anyone.

Most importantly, there is no mechanism built into the language to easily find, access and load them.

What I would envision is something like:

    an easily accessible centralized repository (as simple as a User Command File in the DropBox would be)
    rules for documenting utilities so that they all would be documented using a similar way
    a simple submission mechanism for publishing a utility
    maybe a moderator that would control submissions

What do you all think?

Personally I would be more than willing to give out some of my utilities (which I already started to do with LC.Charts and LC.zREngine)
Posts: 52
Joined: February 8th, 2007, 7:55 pm
Location: Paris, France

Re: Packages for APL64

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

A fine concept, but I can't envision how it would be implemented. Many people have tried this before and nothing has come of it. Rex Swain even tried a few years back and he and I couldn't even come to a consensus on how best to represent dates, much less the utilities needed to process them.

Another issue is that APL programmers are SO very different from one another that even the style of utilities are incompatible with one another. Also, in most other languages it's so difficult to build such libraries that people will go out of their way to use something that's already built, while APL makes it easy to "roll your own" and almost every APL programmer has done so already. Most people, I think, don't much like the idea of using other people's stuff when they already have and use most of what they need and would rather build their own for anything they don't have. So there's a big mindset problem out there that we need to contend with as well.

OTOH, I don't think that building it into the language is necessary. An APL-programmed interface to whatever we want should be easy enough to implement and use, such as with a user-command file.
Davin Church
Posts: 504
Joined: February 24th, 2007, 1:46 am

Re: Packages for APL64

Postby Ajay Askoolum » October 14th, 2018, 4:02 am

APL already has packages in the guise of user commands.

I would like to see data structures, like R's Data Frame as a standard means for

1. holding data ... named elements
2. passing it as a parameter to functions
3. printing
4. transfer.

Nested arrays, for all its obvious merits:

1. has too many pathways for construction.
2. is too anonymous -- its elements impart neither a name nor a purpose

Visual Basic, VBScript, VBA, C# etc all have nested arrays but are not as critical to their context as with APL, precisely for the reasons above.
Ajay Askoolum
Posts: 710
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom

Re: Packages for APL64

Postby Davin Church » October 14th, 2018, 12:20 pm

I think being able to add names (and/or attributes) to elements of a (probably nested) array would have it's advantages, but I'm not sure how to make it work without a radical redesign in APL functionality. C-type structures seem pretty artificial to me in terms of APL's basic design. Perhaps something could be worked out by making it part of the .Net interface extensions?
Davin Church
Posts: 504
Joined: February 24th, 2007, 1:46 am

Return to APL64 Project

Who is online

Users browsing this forum: No registered users and 1 guest