[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Louis de Forcrand
Subject: Re: [Bug-apl] Feature suggestion: multiple function arguments
Date: Sat, 5 Mar 2016 16:17:59 +0100

Then again, I feel the goal of GNU APL is really to implement a complete, sturdy,
and (eventually) fast version of the standard. If some extensions are implemented,
then why not implement all of them? If Jürgen prefers to polish off an exact copy
of the standard before adding features, then let’s respect this decision and keep
that goal in mind when reporting bugs.


On 05 Mar 2016, at 16:09, Louis de Forcrand <address@hidden> wrote:

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
This isn’t very important, although it would eliminate huge function headers if
many variables are used.


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. :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]