:Andif versus :Orif

General APL language issues

Re: :Andif versus :Orif

Postby gil on Sat Apr 21, 2018 6:26 am

Sorry Tomas, I didn't read this properly:
Imho this is how it should work:
- If it's an :If/:Andif/:Andif... chain, it shoud execute anything in between until the first ":Andif 0".
- If it's an :If/:Orif/:Orif... thingy, it should execute in-betweens from the first ":Orif 1" onwards.

or as Phil put it
:AndIf acts exactly like ∧\ (and scan) but :OrIf behaves exactly unlike ∨\ (or scan) while both scans are associative.

makes perfect sense. My comment was only to say that I agree the current implementation feels wrong and is less intuitive (also hard to modify when you come back to it at a later date).

Good luck getting that changed now ;)
Posts: 55
Joined: Mon Feb 15, 2010 12:42 am

Re: :Andif versus :Orif

Postby Phil Last on Sat Apr 21, 2018 7:23 am

OK, so you're serious. You'd like Dyalog to change it! I think we all agree that it's fairly senseless at the moment apart from Kai's point that intervening code prepares the next :OrIf if all previous failed.

I can't see Dyalog doing that. But I'm all for brevity.

How about
:if 0
:Or 0
:Or 1
:Or 1 ⍝ skipped?
Tomas's suggestion appears to entail skipping the :Or that I've comment as such. This might be questionable but would be perfectly understandable.

As to any complaint that :Or is a prefix of :OrIf, so is :Else a prefix of :ElseIf.
User avatar
Phil Last
Posts: 461
Joined: Thu Jun 18, 2009 6:29 pm

Re: :Andif versus :Orif

Postby JohnS|Dyalog on Sat Apr 21, 2018 11:51 am

We can't change :OrIf now because it would break people's apps. The only way open to us would be to invent a new, alternative keyword with a more desirable behaviour. Any suggestions?

On a related note: I believe Bob Smith was considering an :AndIf equivalent for NARS 2000's AFOs (dfn/ops).
Code: Select all
    :If p ⋄ :AndIf q ⋄ :AndIf r ⋄ this ⋄ :Else ⋄ that ⋄ :EndIf
    {p: q: r: this ⋄ that}
User avatar
Posts: 173
Joined: Wed Sep 10, 2008 10:01 am

Re: :Andif versus :Orif

Postby Tomas Gustafsson on Sat Apr 21, 2018 12:47 pm

Phil Last wrote:OK, so you're serious. You'd like Dyalog to change it!

Well, nah, not really. This discussion clarified how it works but it's not a major issue, more like i feel it's a waste of :Orif, to not utilise it more gracefully. Not worth a change.

JohnS|Dyalog wrote:{p: q: r: this ⋄ that}

Feels tempting. A bit of more control in dfns would be useful, for my part i sometimes have to trick with inner dfns to get it right.

(Sorry for diverging from topic and going into dfns): In a dfn, a (rather big) problem is that one can only once call a method that doesn't return a result. The dfn exits at that point, as a result cannot be assigned anywhere. Would it be possible to preceed the method call with something small, that allowed to remain in the dfn?

Code: Select all
{DotNetMethodThatReturnsNothing ⍵ ⍝ Jumps out here
    a←1 ⍝ Never executed

Code: Select all
{:DotNetMethodThatReturnsNothing ⍵ ⍝ Stays
    a←1 ⍝ Executed

OR use some other kind of structural management? (Isn't the "nothing to left of colon" free btw?) Maybe there would be a gap for slightly extending control/structuring in dfns, including this option to remain insidee..
Tomas Gustafsson
Posts: 91
Joined: Mon Sep 19, 2011 6:43 pm


Return to Language

Who is online

Users browsing this forum: No registered users and 1 guest