Hi, Ah I see if it conflicts when probably there is no way to introduce it. Thanks for digging into it!
Juergen Sauermann <juergen.sauerm...@t-online.de> writes: > Hi Alexey, > > it actually does create conflicts. > > In IBM APL2 and in GNU APL, the expression > > ⍺ (f g h) ⍵ > > gives a 3 item vector with the items being ⍺, (f g h), and ⍵. > In Dyalog APL it gives (quote): > > (⍺ f ⍵) g (⍺ h ⍵) ⍝ dyadic (fgh) fork > > Therefore this feature would introduce an unnecessary incompatibility with > IBM APL2. > > For a small project like GNU APL, compatibility with at least one major > vendor (in this > case IBM) is essential, and I am not inclined to sacrifice APL2 compatibility > for a > rarely used feature. And the fact that it took Dyalog 14 releases to > introduce it tells me that > this feature is not very important. > > /// Jürgen > > On 03/13/2016 05:31 PM, Alexey Veretennikov wrote: > > > 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
