Interpreter-based APL utilities

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

Interpreter-based APL utilities

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

As I recall from long ago, in APL2 it was possible for system programmers to write (often as a model) new code in APL and have it compiled into the interpreter to act similarly to a system function. What about adding that as a feature in APL64 so that new language features could be modeled and debugged as APL code and eventually replaced with a C# version after it has been proved to work well, or even left in APL as a permanent language feature if it's fast enough.

Such a feature might be made available by allowing external DLLs as language extensions so that users could write and test their own software as "external DLLs", perhaps connected as special quad-names (such as ⎕X... or similar). Or a similar capability might also work within the concept of compiling APL code into MSIL/Assemblies to do similar things (though it would probably require a separate ⎕NA connection rather than being built in as a native function call).
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Re: Interpreter-based APL utilities

Postby Ajay Askoolum » October 14th, 2018, 3:39 pm

The idea is good.

But there are serious difficulties in practice. With []cse, I can write a C# DLL, load it and call functions within it. So far, so good.

If the arguments to the functions are scalars (single number or string vector), it works fairly well.

If the arguments are arrays, you have to have made provision for the array as a property in the DLL, assign the property to have your APL array, and then call the function which should reference the property. This gets out of hand quite rapidly - you need a property for every type of array e.g. rank. Other problems are:

1. Unlike APL, no other language has trailing padding using spaces for literal arrays.
2. APL arrays transiting via an external DLL quite often become transposed.

I am sure that I am not imagining this (I say that because I cannot remember much about it let alone recreate it). With APL*PLUS/PC (I think it was version 4.0), we had a configuration whereby memory was shared by APL and another application. Either could read/modify/create objects in the shared memory and it was available to the other. The memory used was above the 640K threshold - we had computers with 1MB memory!

The closest idea I have for replicating this arrangement today is to work with shared memory mapped files. I can't comment on the viability of this approach without implementing it - it is liable to be very time consuming.
Ajay Askoolum
 
Posts: 884
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom

Re: Interpreter-based APL utilities

Postby Davin Church » October 14th, 2018, 4:56 pm

I feel like I'm misunderstanding you. I'm talking about writing APL code to interface with APL code using APL variables, without C# or other such languages being involved at all (unless it becomes part of the base interpreter).

What am I missing in your discussion?
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Re: Interpreter-based APL utilities

Postby Ajay Askoolum » October 14th, 2018, 5:21 pm

If you are talking about wrapping APL functions into a free standing DLL and the ability to use the functions within by just using a reference to that DLL, it is a very different matter.

I am not at all sure how you would write a DLL containing APL functions. (Doesn't that imply that every definition will reside in a single file (editor session)?)

It might be simpler to have an arrangement whereby you could call functions using workspace prefixes e,g,

workspaceName.functionWithin(arg1...argn)

You'd maintain the function by loading the workspace but use it from another workspace by explicitly referencing the containing workspace. (Would do wonders for eliminating name collisions).

1. It might work when the active workspace and the referenced workspace are in the same folder.
2. Would become quite complicated if you had to qualify the referenced workspace (or dll) by location.
3. Would become quite complex with dependencies on other functions within the referenced workspace.
Ajay Askoolum
 
Posts: 884
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom

Re: Interpreter-based APL utilities

Postby Davin Church » October 14th, 2018, 6:47 pm

Well, in the old days, as far as my understanding and memory took me, the developers could write APL code and actually compile it into the interpreter. That way it was always available in the system much like a quad-fn. Back then, they didn't have quad-fns, but they had "magic" APL functions with reserved names. For even more ancient examples from the 70's, do you remember ∆FMT or SVC (component file access)?

I think our APL2 installation had a named operator called PEACH that was actually APL code under the covers. If you ran this function it did a normal APL function-call but to a pointer in the interpreter that held the APL source. It then executed those lines of APL as stored in the interpreter's address space instead of executing code that's stored in the workspace, but it was the same kind of APL code executed in the same way as normal - it just wasn't physically IN the workspace at all. The symbol table for that name simply pointed to a different address to find the function to execute.
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 1 guest

cron