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.
Louis > On 05 Mar 2016, at 16:09, Louis de Forcrand <ol...@bluewin.ch> 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 > 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 <loke...@gmail.com >> <mailto:loke...@gmail.com>> wrote: >> >> On 5 March 2016 at 19:29, Juergen Sauermann <juergen.sauerm...@t-online.de >> <mailto:juergen.sauerm...@t-online.de>> 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 >
