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

[Juergen Sauermann]

Hi Peter,

I would say that we have such a mechanism already in GNU APL, namely native functions.
With the current SVN you can even override built-in functions and maybe (never tried, though)
introduce new APL characters/symbols.

One can imagine a number of extension mechanisms:

1. shared variables, ⎕SVN and friends. Slightly outdated
2. new APL characters (typically ⎕AV members that currently have no APL relevance)
3. new ⎕-functions and variables
4. native functions, can trigger 2. or 3.
5. new APL Syntax

Of the above I personally consider 1-4 as reasonable and 5. as outright bad and not desirable.
For several reasons:

1. changing the parser is a cumbersome and error-prone undertaking,
2. a changed syntax cannot be easily emulated on a different APL system,
  so it creates serious portability problems. Portability problems (read: customer lock-in)
 are a valid strategy for commercial programs but are, in my opinion,  an absolute no-go
  for  a free APL. We cannot seriously fight for free software and at the same time enable
  lock-in mechanisms for the software we write.
3. Most syntax changes that I have seen for APL could have been easily replace by other means.
4. With every syntax the language gets more non-standard and, in my opinion, less readable (at least for
those that are not familiar with the syntax).
5. I strongly believe that the most successful languages so far were those that managed to keep their syntax simple
   and used other means for extensions, typically libraries.
6. adding a new syntax is a waste of time.

To summarize, I believe that we have a number of extension mechanisms 1.-4. already in place, and the
only missing one (5.) is a bad one that should be avoided.

I also agree that branching the trunk is not good. But the existing extension mechanisms do not require that.
The emacs_mode and sql modules, for example, that native functions are powerful enough to extend GNU APL
in a modular way. In a way, native function are the Plugin API of GNU APL. They allow you to extend GNU APL,
quite easily and extensively. The only thing that you cannot (and according the to above should not) do is to
add a new APL syntax.

/// Jürgen

On 03/15/2016 03:55 AM, Peter Teeson wrote:

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