APL Control Structures 
Author Message
 APL Control Structures

We at IBM have been watching the discussion of control structures
with some interest.

I would like to relate some recent history from my/our perspective.

A couple of years ago I watched Rob Willhoft present his
proposal for control structures.  I believe it was at Minnowbrook.
As I recall, many people in the room thought his proposal
was terrific; I know I did.

I came home and tried to interest my colleagues in Rob's
proposal.  I guess I didn't do a very good job, because it
took a year to convince Jim (Brown); when Jim heard Rob
present the proposal again at the annual APL conference, he
was also sold.

We now agree we like and would like to implement Rob's
proposal.  (BTW, I remember that at least one of the other
vendors left that initial Minnowbrook with the comment that
they were going to implement Rob's proposal right away; it
hasn't happened.)

We prefer Rob's approach of extending a little used portion
of the syntax over the addition of English words.

In any case, there is another concern.  While this is a hot
topic on c.l.a right now, there are other hot topics too.
Things like support for new platforms, GUI, performance,
improved portability, and better interfaces to the outside world.
Depending on which group you talk to when, one or more of
these other topics has seemed more important than control
structures for the last few years.

Yes, let's talk about this at APL94.  If you have an opinion
on this topic, or any other design topic or requirement,
please feel free to drop us a note or stop by the booth
at the conference.

Regards,
David Liebtag
IBM APL Products and Services



Tue, 18 Feb 1997 04:39:06 GMT  
 APL Control Structures

Quote:

>We prefer Rob's approach of extending a little used portion
>of the syntax over the addition of English words.

Please do not take away the "delta", or do anything else to break existing
code.  Is there any real difference between Rob's approach and Manugistics',
other than the actual tokens involved?

Quote:
>In any case, there is another concern.  While this is a hot
>topic on c.l.a right now, there are other hot topics too.
>Things like support for new platforms, GUI, performance,
>improved portability, and better interfaces to the outside world.

You'll have to figure out market demand and competition :-)




Tue, 18 Feb 1997 21:46:15 GMT  
 APL Control Structures

Quote:

>>We prefer Rob's approach of extending a little used portion
>>of the syntax over the addition of English words.

>Please do not take away the "delta", or do anything else to break existing
>code.  Is there any real difference between Rob's approach and Manugistics',
>other than the actual tokens involved?

Yes. Go read his article in the  Proceedings of APL93: ACM SIGAPL
Quote Quad, Volume 24, no. 1, August 1993.

In reply to a posting by David, I have to say that I am not very
impressed by Willhoft's symbolism in his structures, and prefer the
Manugistics and ISI approaches to this problem. They have the advantage
of being recognizable to non-APLers [Willhoft's stuff will NOT be
immediately decipherable by APLers either]. Here's an example
from Wilhoft:
     DEL:  x EPSILON 2 0 NEGATIVE 2
          {lines of APL code}
     DOWNARROW:
     JOT:    
          {lines of APL code}
     DELTA:

{APL characters in caps above, because this here Xterm and this here
 net don't have APL symbols, but you knew that already}

Quote:

>>In any case, there is another concern.  While this is a hot
>>topic on c.l.a right now, there are other hot topics too.
>>Things like support for new platforms, GUI, performance,
>>improved portability, and better interfaces to the outside world.

>You'll have to figure out market demand and competition :-)

Market and attention to client-centered design suggests that the
Willhoft approach will NOT be readily accepted by a large part
of the computing community. I don't CARE if it's accepted by
APLers or not -- they're NOT the people we have to attract to APL!

Now, with regard to performance, regardless of which design is chosen for
structured controls, all of them offer the potential for
improved performance in APL. In particular, in compiled APL, there
is the chance for simple vectorization and parallelization of code,
which is difficult {not impossible, merely difficult} to detect
even in well-written code.

Those who spout lines like:  "Well, I prefer to use APL's array
primitives and built-in control structures for my work, rather than
write loops", simply are not writing real-world applications
where looping [whether with branch or with structured controls]
is the ONLY solution. Examples of these include:

a. dynamic programming
b. Most serious numeric applications -- Simplex, Gauss-Jordan,
   FFT, PDEs...
c. Very Large Files
d. Compilers, parsers, and interpreters
e. Real-time systems

and so on.

Bob



Wed, 19 Feb 1997 03:02:21 GMT  
 APL Control Structures

Quote:


>>>We prefer Rob's approach of extending a little used portion
>>>of the syntax over the addition of English words.

>>Please do not take away the "delta", or do anything else to break existing
>>code.  Is there any real difference between Rob's approach and Manugistics',
>>other than the actual tokens involved?

>Yes. Go read his article in the  Proceedings of APL93: ACM SIGAPL
>Quote Quad, Volume 24, no. 1, August 1993.

Other than a provision for variables local to a block, I fail to see what
is really different.  He mentions "local definitions" in a short, ten-line
paragraph near the end, and then suggests lexical scoping, but provides
no syntax for their definition or use.  As I said before I'd very much like
to see an elegant proposal for multi-line local functions.  I suggested
dyadic -> as GOSUB.




Wed, 19 Feb 1997 04:39:24 GMT  
 APL Control Structures

Quote:
Robert Bernecky writes:
>In reply to a posting by David, I have to say that I am not very
>impressed by Willhoft's symbolism in his structures, and prefer the
>Manugistics and ISI approaches to this problem.

 I am also pleased with the ISI approach to the problem, but I would
 like it much better if they provided a 'for' construct. To me :

 n =. 5
 i =. 0
 while n > i do.
 NB. j code
 i =. increm i
 end.

 is messy.

 Also, ISI has not yet set their policy regarding J8 source.
 The new control structures and new definition of amend
 make it so that one has to maintain separate code for UNIX
 and PC versions of the same function. I'm not too pleased
 about that either :)

 -e



Wed, 19 Feb 1997 05:05:40 GMT  
 APL Control Structures
Here are three orthogonal, complementary proposals for adding control
structures to APL.  Critiques are welcome.

(1) Controlled statements

<WHILE>  {control} -> {block}
<IF>     (control) -> {if-block} {optional-else-block}
<CASE>   (control) -> (case1) {block1} ... (caseN) {blockN} () {default}

The empty parentheses () can be omitted; so can a case value of 1.
Thus, the CASE statement is a non-boolean extension of the IF statement.
Line-breaks are allowed inside the {} delimited blocks, and diamond
separators <> are allowed inside a line.  Multiple lines or sub-blocks
inside a {block} are executed top to bottom.

The "extent" of a line label is the block in which it appears, including
sub-blocks but not super-blocks.  Each function is considered a block.
Thus, one may use the -> to go to the beginning or end of loops.
On the other hand, branching into a block is disallowed.

(2) Controlled expressions

<EXPR>   {expr1} {expr2} ... {exprN} [control]

This is interpreted as indexing a strand, with lazy evaluation.  
If the control is a vector or matrix, the expressions are executed
or repeated in ravel order.  A vacuous control [] results in the vector
(expr1),(expr2),...,(exprN) but evaluated in the order 1 to N.  
If control is an empty array, the result is also empty but otherwise
"undefined" (i.e. left to the implementation).  Each {expr} that is
executed must yield a result; the "left-tack" may be used to string
together several expressions within an {expr}.  Line-breaks are allowed
after a left-tack; order of execution is bottom to top within an {expr}.

(3) Local functions and subroutines

<GOSUB>  (control) -> label(val1;val2;...;valN)
<DEFN>   label (arg1;arg2;...;argN) ;local1;...;localK : {block}
<RETURN> <- optional-result

Control is a simple boolean.  Local definitions can be nested and are
lexically scoped.  Indeed, they may appear inside any block.  However,
the definition "label" must begin a new line.  If there are no arguments
the () can be omitted.  Results can be returned explicitly with a
"<- (value)" statement.  Recursive call is "undefined" for the time being,
but probably a good idea.  

Minimal call overhead is a goal, and restrictions (such as macro or
call-by-name semantics, no recursion or only tail recursion, etc.) may
be added...

Are these proposals detailed enough?




Wed, 19 Feb 1997 06:28:18 GMT  
 APL Control Structures

Quote:

>Robert Bernecky writes:

>>In reply to a posting by David, I have to say that I am not very
>>impressed by Willhoft's symbolism in his structures, and prefer the
>>Manugistics and ISI approaches to this problem.

> I am also pleased with the ISI approach to the problem, but I would
> like it much better if they provided a 'for' construct. To me :

> n =. 5
> i =. 0
> while n > i do.
> NB. j code
> i =. increm i
> end.

> is messy.

I concur. Also, taking code apart to locate induction variables in
examples such as the above is a royal pain, for either a compiler
{If someone knows of work which can describes how to do this automatically,
please email me on it!} or for someone trying to maintain the code.

Quote:
> Also, ISI has not yet set their policy regarding J8 source.
> The new control structures and new definition of amend
> make it so that one has to maintain separate code for UNIX
> and PC versions of the same function. I'm not too pleased
> about that either :)

I expect this will be resolved relatively soon. It's clearly a problem
as things stand. I am trying to run J on both UNIX and PC platforms as well.

Bob



Sat, 22 Feb 1997 22:50:55 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. APL control structures -- new

2. Proposal for control structures in APL

3. Proposal for control structures in APL

4. Proposal for control structures in APL (SAMSON)

5. Control Structures in APL

6. Control Structures in APL

7. Control structures in APL

8. Control structures in APL

9. Control structures in APL

10. control structures in APL

11. Control Structures in APL

12. Control structures in APL

 

 
Powered by phpBB® Forum Software