In principle I agree with you. There are many occasions where an IF statement in particular is useful, or even necessary. However, implementing it in GNU APL would take careful consideration, and I know Jürgen wants to make sure any new extensions doesn't contradict the principles of what APL is.
The problem is that these imperative structures don't blend very well with the array-nature of APL. Something as simple as the distinction between true and false becomes tricky. What should the following program print?
a ← 2 2 ⍴ 0 1 2 3
IF (a)
⎕←'foo'
ELSE
⎕←'bar'
ENDIF
The above is just one of the examples where the linear nature of imperative code collides with the parallel processing of arrays in APL.
That said, like you I also think it's a worthwhile thing to try, so I started working on KAP, which is my experimental APL implementation precisely because I wanted to explore these things. This way I wouldn't have to worry about making something that contradicts the principles of APL, since my language isn't APL, it's just mostly compatible with it. When looking at existing APL's with imperative constructs, I found that the ones in Dyalog were not only ugly, but also very limited. In particular I found that making IF a statement is unnecessarily limiting, and I wanted to make it an _expression_ so that something like this would be possible:
x ← 100 + if (a) {foo} else {bar}
The above would add 100 to either foo or bar, depending on whether a is true or false (for some definition of true/false).
What I eventually settled on was a construct called "defsyntax" that allows a user alter the parser so as to provide this functionality without actually changing the core language. In other words, features such as IF/ELSE, WHILE, etc are defined in the standard library instead of actual language features. Here's how IF is defined in KAP:
defsyntax if (:value cond :nfunction thenStatement :optional (:constant else :nfunction elseStatement)) {
⍞(((cond ≡ 1) ∨ ((1=≢cond) ∧ (↑cond) ≡ 1)) ⌷ (⍞((isLocallyBound 'elseStatement) ⌷ λ{λ{⍬}} λ{elseStatement}) ⍬) thenStatement) cond
}
If you try to understand the above, please know that ⍞ is completely different compared to APL. In KAP, ⍞ is used to apply a closure to some arguments.
Regards,
Elias
well I saw the new thrends aka Quad-XML, Quad-JSON, Quad-FFT and so on
but I think thoses will never be used in real life or quite seldom.
I really think that Juergen should be looking at
:if/:elseif/:else/:endif
:for var :in array
loop
:endfor
:while condition:
loop
:endwhile
:do
loop
:until condition
this will eases newcommers to the language.
I know that APL goal is to do a whole "program" in one or two lines of code...
but the language must accomodate newcommers.
I asked for that several years ago (may me 8 or 10 years)
Juergen ansewered at that time "this can be done" but I wont yet
well my principal next improvements wish list is if/for/while/do_until
my real though,
Xtian.