bug-apl
[Top][All Lists]
 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 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 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 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 wrote: On 5 March 2016 at 23:28, Louis de Forcrand 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 ```