Hi, At first I also thought like this, but since it is already part of J language and Dyalog APL, and it is not something alien but rather invented by Ken Iverson himself, I believe it could be a part of language if it does not produce conflicts.
>From what I understood the general idea is to have something like this from a mathematical notation: f(x)+g(x) <=> (f+g)(x) which is used a lot in Analysis for example. Hence keeping that in mind forks and trains are not something alien, but rather useful and elegant concept. For example I can take this Wikipedia page: https://en.wikipedia.org/wiki/Mean and directly implement all these 3 means with trains. In order to do this I just need to think about the following: 1) what is the "central" operation (in all these cases it is either a division ÷ or power *) 2) What is the dividend 3) What is the divisor and I can build these 3 means rather natural: Arithmetic Mean (AM): AM←+/÷≢ AM ┌─┼─┐ / ÷ ≢ ┌─┘ + AM 4 36 45 50 75 42 Geometric mean (GM), where the power is a central operation: GM←×/*(÷≢) GM ┌─┼──┐ / * ┌┴┐ ┌─┘ ÷ ≢ × GM 4 36 45 50 75 30 and Harmonic mean (HM): HM←≢÷(+/÷) HM ┌─┼──┐ ≢ ÷ ┌┴┐ / ÷ ┌─┘ + HM 4 36 45 50 75 15 All of these feels rather natural to use actually. Juergen Sauermann <juergen.sauerm...@t-online.de> writes: > 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 > > > > > -- Br, /Alexey
