bug-apl
[Top][All Lists]
Advanced

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

Re: [Bug-apl] This looks wrong


From: Juergen Sauermann
Subject: Re: [Bug-apl] This looks wrong
Date: Wed, 06 Aug 2014 17:15:33 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5

Hi Elias,

I am a friend of orthogonality and symmetry.
And I like David's "principle of least surprises".

In GNU APL lambdas behave like (and in fact are) defined functions.
If we would dis-allow niladic lambdas, then by the same token, we should
dis-allow niladic defined functions (and probably niladic system functions
as well?). I am afraid some users may complain then.

You cannot pass niladic lambdas to operators and you cannot pass niladic functions
to operators either. Fair enough - just make them monadic. I would do that with suffix ⊣⍵
rather than with prefix ⍺⊢.

But the fact that you cannot use niladic lambdas for one purpose does not make them useless
for other purposes. Therefore I believe we should leave matters as they are.

/// Jürgen



On 08/06/2014 03:15 PM, Elias Mårtenson wrote:
I have been looking at how Dyalog does it, and their implementation is even more strange. I have to agree with your assessment.

Last night as I was about to go to sleep I thought about a change that could make the use of "side-effect-only" lambdas much more logical and functional. It sounded great to my inner mind before I went to sleep, so at least I feel it should be discussed here.

My suggestion is that niladic lambda functions will not be allowed at all. Instead, they will be interpreted as monadic functions that ignore their argument.

The justification for this is as follows:
  • Niladic functions can't be passed to operators, so they are useless for that.
  • If the niladic lambda is parsed as a monadic function, things like this would be possible again: {⎕←'hello'} REPEAT 10
  • Thus, the only use for niladic lambdas would be to assign them to a name: foo←{2}
  • To deal with the above, there are two different approaches:
    1. Such assignment will result in foo being a dyadic function, or
    2. A niladic lambda can remain niladic when assigned to a variable
Regards,
Elias


On 5 August 2014 23:47, Juergen Sauermann <address@hidden> wrote:
Hi,

this is how I read the ISO standard. If a statement that is valid per ISO returns
a wrong result then I consider that a fault that should be (and was) fixed.

If that conflicts with an intended use of a non-standard extension like the ⍣ operator then I
would rate that as simply bad luck (as opposed to a fault).

/// Jürgen



On 08/05/2014 04:40 PM, Elias Mårtenson wrote:
Are you sure we want to fix that though? Things like the power operator (once we have it) will not work right (since it's seems to be often used to execute a niladic function a certain number of times.

The SQL∆WithTransaction will have the same problem.

The workaround seems to be a bit ugly, like prefixing the lambda function with ⍵⊢

Regards,
Elias


On 5 August 2014 22:07, Juergen Sauermann <address@hidden> wrote:
Hi David,

thanks, fixed in SVN 417. Unfortunately, as a consequence, it is no
longer possible to pass a niladic function to an operator.

/// Jürgen



On 08/05/2014 09:39 AM, David B. Lamkins wrote:
Maybe I've misunderstood some APL2 corner case, but the behavior of the
attached program seems wrong.








reply via email to

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