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

[Juergen Sauermann]

Hi, after looking at the examples in the Dyalog  APL Programmer's Guide, I don't think that forks and trains are something that should be added to GNU APL. In my opinion, one of the strengths of APL is its syntactic simplicity, and these constructs go into a different direction. /// Jürgen On 03/12/2016 08:22 PM, Alexey Veretennikov wrote: Thanks for the info! I've watched the Morten Kronberg's talk at Google(available on youtube) and he described how Ken Iverson got to the idea of forks. Only after this description of the roots of it I finally got the idea; I think it is great what forks ended up in the Dyalog APL since for me personally J is a non-choice because it lacks APL notation (and therefore part of it charm). Would be awesome to have support for forks and other modern syntax in GNU APL with some compatibility mode (in Dyalog one can run the interpreter in IBM APL2 compatibility mode instead of Dyalog one by changing the system variable ⎕ML) Jay Foad <jay.f...@gmail.com> writes: FYI Dyalog version 14 has forks. You can try it at tryapl.org: http://tryapl.org/?a=%28+%u233F%F7%u2262%291%202%203%204&run Jay. On 5 March 2016 at 17:17, Louis de Forcrand <ol...@bluewin.ch> wrote: To add to the confusion, while ( {+⌿ ÷ ≢} y) ≡ ( +⌿y) ÷ ≢y (x {+⌿ ÷ ≢} y) ≡ (x+⌿y) ÷ x≢y whatever that does. I completely agree, it’s quite obscure, especially if one is not accustomed to tacit definition. This by the way is a fork, and is basically a way to avoid parentheses. More useful however is the bonding operator, which I know is functional in Dyalog: toCelsius ←((5÷9)∘×)∘(-∘32) toFahrenheit ←toCelsius⍣¯1 toFahr toCelsius 212 212 Which can be very handy. Louis On 05 Mar 2016, at 16:33, Elias Mårtenson <loke...@gmail.com> wrote: On 5 March 2016 at 23:28, Louis de Forcrand <ol...@bluewin.ch> wrote: That would be a great idea. However, it would indeed take not only quite a bit of time to set up, but would also need constant checking to make sure the updates in the main branch don’t conflict with additions. While I just said that I believe the main branch should probably concentrate on the standard, one of the things I’ve really fallen in love with in J and that is completely missing in standard APL is tacit definition. Not only does it allow inversible functions and idiom detection for optimisation, but it is just simply so elegant: mean ← +⌿ ÷ ≢ This is where we disagree, but nothing wrong with that. I can certainly understand why someone would like that construct, but I just don't like it at all. I think this is probably the least clear and easily the most confusing language construct I know of in any language I have tried. I would certainly like to see some simpler way to define such functions without multiple levels of lambda definitions, but the J model is not the right way, in my opinion. Regards, Elias