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.
If you want to experiment with these things, my project is open to anyone
who wants to help out: https://github.com/lokedhs/array
Regards,
Elias
On Sun, 21 Feb 2021 at 02:59, Christian Robert <christian.rob...@polymtl.ca>
wrote:
> 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.
>
>
