Re: [Bug-apl] Feature suggestion: multiple function arguments

[Peter Teeson]

Hi Jürgen:

Thanks for your patient reply. 

I fully understand what your explanation and consequently the functionality provided.

Thank you so much for having made GNU APL… a major contribution to the APL community IMHO.

respect….

Peter

On Mar 17, 2016, at 10:16 AM, Juergen Sauermann <address@hidden> wrote:

Hi Peter,

almost. Except that you should not (and cannot, and need not) use the name ⌶ but instead a normal, user-defined
APL name.

The old ⌶ (and also ⎕-names) were old "hacks" to achieve a particular purpose. But they have considerable downsides:
localization, parser impacts, and source code portability.

If we instead use normal user-defined names for introducing new functionalities then we have no parser impacts
and another platform can emulate that functionality via a normal user-defined APL function (that may then call
specific functions in the other platform if available).

In practice this makes life rather simple:

1. You write a shared library, say my_lib.so.
2. contains the implementations those function header combinations that you want to provide.
  For example 'Z←A f B', 'Z←f B' and 'Z←f[X] B'
3. You bind the my_lib.so to an user defined APL name, for example  'my_lib.so' ⎕FX 'NEW_FUN'

Step 3 has then created a new APL function NEW_FUN that, when called, executes the code in mylib.so.
More precisely, when you call A NEW_FUN B in APL then the first implemented header will be executed,
when you call  NEW_FUN B then the second implemented header will be executed, and with  NEW_FUN[X] B
the third implemented header will be executed.

All this still follows APL syntax and therefore the parser is not involved (the magic happens below the parser level).

Your shared library has full access to the APL Interpreter at two points in time: when it is ⎕FX'ed and when the
⎕FX'ed functionis called. That means it can (as a side effect) create, modify, or delete APL variables, and you
can even overload or extend the implementation of every build-in APL function (primitive functions, operators,
and ⎕-functions).

I believe all this gives us a lot of freedom to extend GNU APL within the boundaries of the APL syntax so that I
can't see why we would need to change that syntax of APL if all we want to do is extend its functionality.

/// Jürgen

On 03/16/2016 10:46 PM, Peter Teeson wrote:

Hi Jürgen:

Thanks for your patience… I am probably still somewhat stuck in my time-sharing mainframe days.

If I understand you correctly you are saying that I can make a shared library let’s say with a name ⌶?

I haven’t tried making such a named library/plugin - Is it going to be possible to name it using the ⌶ symbol?

e.g. On my keyboard using MacAplAlt as a keyboard source it’s 

option+shift+1 i.e. Unicode U+2336 ( which is the APL functional symbol I-Beam).

Presently GNU APL gives me "No token" when I enter it.

Then ⎕FX it and have an apl _expression_ X⌶Y and another apl _expression_ Xº∘Y?

Where the 2nd _expression_ uses the GNU APL outer product implementation and the first uses my implementation?

( ⌶ could be an implementation of train, or fork, or whatever a programmer would like to try as a language extension

or operator speedup or more advanced algorithm, or non homogenous arrays because nested is not elegant, etc).

Suppose it is — will the GNU APL interpreter then recognize it as a token and 

 "call into my library" passing me the environment? 

Which is what I would like it to do. This is the key question and idea that I am proposing …..

Which is why the ⌶ symbol gets parsed in the interpreter as though it were an apl symbol.

In ⌶ will I have access to the stack, heap, and so on?

Of course that’s dangerous and one must be well behaved but that’s true now isn’t it? 

On the mainframe you had to be at physically at one of the 3 or 4 operator consoles plus also be privileged.

IOW like root on Unix systems - sudo s. Of course on single user systems being root is not really necessary.

If so maybe your suggestion works for me because the _expression_ X⌶Y looks aplish.

Anyway that’s what I have been thinking / imagining….. 

respect…

Peter

On Mar 16, 2016, at 1:36 PM, Juergen Sauermann <address@hidden> wrote:

Hi Peter,

I am not quite getting why you would need the I-beam thing in the first
place (or why you would need to involve the parser).

If all you want is to write something in assembler (and then call it from APL), then

- Pick a suitable user-defined name for it,
- Put the assembler (or C or FORTRAN or whatever) into a shared library,
- ⎕FX the shared library under the chosen name

From then on a call to the name will call the assembler code, passing the arguments
given to the assembler code and it will return the result produced by the assembler code.

No need for new ⎕AV symbols or ⎕-names or I-beams or such.

That IS a plugin in the form of a shared libraries. Many plugins are build like this these days.

And it works already!

/// Jürgen