bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jay Foad
Subject: Re: [Bug-apl] Feature suggestion: multiple function arguments
Date: Mon, 7 Mar 2016 09:34:49 +0000

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]