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

[Alexey Veretennikov]

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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> wrote:
>
> On 5 March 2016 at 23:28, Louis de Forcrand <address@hidden> 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