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

[Juergen Sauermann]

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 <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