Newsgroups: comp.lang.apl
From: bowman@apl.demon.co.uk (Dick Bowman)
Path: watmath!watserv2.uwaterloo.ca!torn!utnut!cs.utexas.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!noc.near.net!uunet!pipex!bnr.co.uk!demon!apl.demon.co.uk!bowman
Subject: Re: Control Stuctures in APL 
Distribution: world
References: <1993Apr10.045751.26616@csus.edu>
Organization: Dogon Research
Reply-To: bowman@apl.demon.co.uk
X-Newsreader: Simple NEWS 1.90 (ka9q DIS 1.21)
Lines: 49
Date: Sat, 10 Apr 1993 18:57:26 +0000
Message-ID: <734468246snz@apl.demon.co.uk>
Sender: usenet@demon.co.uk

In article <1993Apr10.045751.26616@csus.edu> vpcsc4@sfsuvax1.sfsu.edu writes:

>In article David.Michelson writes:
>>There ARE some control structures in APL:
>>
>>All dialects support array handling:  1000 + iota 25   does a kind of DO loop.
>>                                      +/ iota 100      does another.
>>
>>Some dialects support diamond:  you can only branch to a line beginning,
>>  allowing you to do setup stuff no one can interrupt and branch past.
>
>   NB.  I'd say you are streching it calling iota a control structure.
>   NB.  And diamond is not a control structure.
>   NB.  But the good news is that Manugistics is adding new structured control
>   NB.  structures and features to their dialect. This might even lead to
>   NB.  renaming their product to INCA for "It's not APL". Also, the language A
>   NB.  at Morgan Stanely also has some structured control constructs.
>
[stuff about J deleted...]

I think David has a valid point here; one of the things that I found out way
back when I was a Cobol programmer (yes, really) was that if you got the data
right the code sort of fell into place round it. Not an original discovery.

Jim Brown made the valid point at APL88 that in APL (and especially in the
dialects that permit nested arrays) the structure of the application was in
the data. Apologies if this is a misquote.

What we see is that since APL views the complete array as the natural
processing unit, rather than looping around scalar instances, we have a
substitution taking place. The EXPLICIT structures that are needed in the
CODE for a scalar language are replaced by the IMPLICIT structures of the
DATA when we use APL. This is why (in my view) we've been able to go along on
our merry way for so many years with a quite crude flow-of-control 
mechanism in our code; and it's a point that doesn't really fall too well
into the comprehension of your typical Fortran/Cobol/etc programmer (or
Computer Science graduate).

But, of course, like all simple theories not all of the facts fit and there
are indeed applications which would benefit from APL having a more
sophisticated flow-of-control mechanism. Most of the designs for such
mechanisms, over the years, have (to my mind) been pretty flawed; but there
may indeed be hope on the horizon. A paper has been doing the rounds which
brings a new proposal to us; the reaction I've seen from many readers is that
they're much more interested at the end of the paper than they were at the
beginning (and how many papers can you say that about?). I hope that the
paper will soon see wider distribution; I hope even more that vendors will
implement these proposals so that we can all experiment with the concepts. No,
I am NOT the author.
