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

[Elias Mårtenson]

I was thinking of something similar, but the problem is that creating a plugin API that lets you implement trains is incredibly difficult, since you need to hook deep into the parser.

As for more simple extensions, we already have almost all that is needed in the plugin API, with the exception of being able to define new function symbols.

The latter is something that I would like very much. In other words, I would like the ability to define functions (single-letter ideally) using characters outside of quad-AV.

Jürgen has previously explained that there are technical difficulties in expanding the character repertoire outside 255 characters, but I still feel this is one old limitation that deserves being eliminated.

Hi all:

The gist of my suggestion is Why not have a Plugin API? Is there any interest is such an idea?

I strongly support Juergen’s position that GNU APL remain an implementation of the ISO Standard.

And that the IBM APL2 implementation is one that it makes sense to use as a comparison.

This in no way denigrates any other implementations and Dyalog in particular has ‘kept the faith’ with 

their promotion and extension of the language.

In April 2014 I remarked on this forum that at IPSA we had a way of experimenting with extensions.

I emailed Bernecky who reminded me that we used an i-beam (overstrike of encode with decode).

This allowed us to link in experimental code, including language extensions. 

This let us have both the current and experimental code available to play with.

Granted this was on our time sharing system.

However it might make sense to define a Plugin API for GNU APL as a way to do 

something similar for experimental purposes. 

I suggest that is much cleaner than many people each branching the trunk.

Permitting a plugin does raise some interesting issues of protection of the interpreter itself.

Perhaps we can adopt the userland vs kernel concept for that. And it’s pretty well understood these days.

My 0.02¢

Peter

On Mar 14, 2016, at 7:58 PM, Louis de Forcrand <address@hidden> wrote:

Although I personally like tacit style, I agree that they shouldn't make
their way into the main branch. It could be interesting to see them
added to a fork (heh) of GNU APL however.

Alexey:
As to the lack of APL symbols in J, I sometimes miss the nice symbols
present in APL. J thus loses some "handwriteability". This shouldn't
however keep you from trying it out; it's quite similar to APL and the
concepts of verb rank and function composition make you think
differently about the way you solve problems. It's definitely worth
a try.

Louis

On 13 Mar 2016, at 19:35, Kacper Gutowski <address@hidden> wrote:

On Sun, Mar 13, 2016 at 6:20 PM, Juergen Sauermann
<address@hidden> wrote:

it actually does create conflicts.

In IBM APL2 and in GNU APL, the _expression_

⍺ (f g h) ⍵

gives a 3 item vector with the items being ⍺, (f g h), and ⍵.
In Dyalog APL it gives (quote):

(⍺ f ⍵) g (⍺ h ⍵) ⍝ dyadic (fgh) fork

I'm not certain whether it does create conflicts or not in general,
but I think this particular example is flawed: ⍺ (f g h) ⍵ could be
anything depending on what name classes those symbols have
(particularly if g were an operator).  When f, g, and h are all
functions, then it's not a vector, but a syntax error.  No conflict
here.

-k