🚀 go-pugleaf

In article <1477@mmintl.UUCP> mmintl!franka (Frank Adams) writes:
>I disagree.  "if/then/else" would be very useful in APL.  You wind up
>using go to (->) instead.  This is bad for the same reason it is bad in
>other languages.  The data structuring somewhat reduces the need for such
>things, but not all that much -- particularly for complex applications.

Suppose there were no MIN primitive, and we wanted to implement it.  The
straightforward approach would yield (uppercase denotes APL symbols)
      DEL z IS x min y
[1]   GOTO (x > y)/4
[2]   z IS x
[3]   GOTO 0
[4]   z IS y
      DEL

However, one can also write
      DEL z IS x min y
[1]   z IS ((x LEQ y) MULT x) + (x > y) MULT y
      DEL
(or variations thereon), which I would consider attrocious programming in a
conventional language, even in a dialect of BASIC that has the same rules.
(No flow control except GOTO, but relational operators yield a value.)  But
in APL, the second method is preferred, because it uses scalar primitives
only -- and hence will work properly when given two compatible arrays.

I just wanted to show that it's not always appropriate to compare APL to a
conventional language, and that if/while is often the wrong way to think
about a problem.

Of course, there are real examples where flow is necessary, which currently
require a GOTO.  The APL equivalent of "do this block n times" is especially
ugly.  I don't know if adding flow control is a good idea or not.  (Some
would argue that the language is so hard to read that proper flow control is
irrelevant.)  I think that it's probably better to graft the useful features
of APL (terse high-level array manipulations) into another language than to
try to fix APL.

>One advantage of a proper implementation of variable declarations is that
>one would be able to define a function as operating on, say, two scalar
>arguments; if invoked with two arrays of the same dimensions, it would
>automatically be called for each corresponding pair of scalars.

Yes.  It would also make it much simpler to write a compiler; currently when
an expression like "foo - 3" is encountered, the interpretation of the "-"
depends on the (unknown) arity of "foo": "foo() - 3" if it's niladic (or a
variable), "foo(-3)" if it's monadic, run-time error if it's dyadic.  There
are compilers for APL, but they have to "guess" -- and have a backup plan in
case the guess is wrong.

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint