Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!mhuxm!mhuxf!mhuxi!mhuhk!mhuxt!houxm!ihnp4!bentley!kwh
From: kwh@bentley.UUCP (KW Heuer)
Newsgroups: net.lang.apl
Subject: APL structure
Message-ID: <858@bentley.UUCP>
Date: Mon, 26-May-86 17:53:20 EDT
Article-I.D.: bentley.858
Posted: Mon May 26 17:53:20 1986
Date-Received: Wed, 28-May-86 01:50:40 EDT
References: <1477@mmintl.UUCP>
Organization: AT&T Bell Laboratories, Liberty Corner
Lines: 50

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