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

[Juergen Sauermann]

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