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 <[email protected]> wrote:
>
> On 5 March 2016 at 19:29, Juergen Sauermann <[email protected]
> <mailto:[email protected]>> 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
