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: Alexey Veretennikov
Subject: Re: [Bug-apl] Feature suggestion: multiple function arguments
Date: Sun, 13 Mar 2016 18:31:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.91 (darwin)

Hi,

Ah I see if it conflicts when probably there is no way to introduce it.
Thanks for digging into it!

Juergen Sauermann <address@hidden> writes:

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

-- 
Br,
/Alexey



reply via email to

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