:Andif versus :Orif

[gil]

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

[Phil Last]

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
   skipped
:Or 0
   skipped
:Or 1
   executed
:Or 1  ⍝ skipped?
   executed
:End

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.

[JohnS|Dyalog]

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}

[Tomas Gustafsson]

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.

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


into

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