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 >> >> > -- Br, /Alexey
