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

[Louis de Forcrand]

While talking about features to add, instead of introducing a new function header

style, IMHO a new local assignment function would be more useful.

For example, instead of typing

∇Z←X F Y;A;B;C

to declare local variables, instead one would simply type

∇Z←X F Y

and then assign variables A, B, and C using the local assignment arrow.

This would apply to the previously discussed header as:

∇multi a

(a1 a2 a3)⍅a

…

I understand this won’t happen, as it would probably require major reworking

of function definition, not to mention the lack of a suitable symbol (although

the one I used is an arrow overstruck by a stile, which in fact is already called

APL FUNCTIONAL SYMBOL … in unicode).

This isn’t very important, although it would eliminate huge function headers if

many variables are used.

Louis

On 05 Mar 2016, at 15:28, Elias Mårtenson <address@hidden> wrote:

On 5 March 2016 at 19:29, Juergen Sauermann <address@hidden> wrote:

IMHO a language does not get any better if it provides
different syntactic constructs for (almost) the same thing. The complexity of the
language is being increased without a noticeable benefit. I would also claim
that the best languages are not those that have the most features, bit those
that have a clean (and, minimal) structure.

While I agree with the general sentiment that generic, minimal structures are better than lots of special cases, one should not always follow that principle without exception.

After all, what is × if not just syntactic sugar for {+/⍺⍴⍵} ?

In my opinion, a better rule of thumb is to look at a proposed feature and determine if it eliminates unnecessary repetition. Your example:

      ∇multi a

      (a1 a2 a3)←a

Does not have much of repetition, and if this was the complete story I'd be 100% in agreement with you. However, you missed one thing:

      ∇multi a;a1;a2;a3

      (a1 a2 a3)←a

Here we can see that there is repetition of the three variables a1, a2 and a3. Whether that repetition is unnecessary or not I will leave to others to judge, but the argument for this extension is certainly a valid one.

That said, I feel that there are plenty of potential extensions that should be implemented that are much more important than this one, so I don't personally care much about this one at all. :-)

Regards,

Elias