Control structures in APL 
Author Message
 Control structures in APL

This year I discovered that Manugistics had implemented
controlstructures the classical way.
-On the one hand I was glad that finally someone had implemented
 control structures in APL.
-On the other hand I was very disappointed that it was done in the
 classical-third-generation-language way.

Coming back from vacation it appeared that this forum had spawned a
discussion about control structures. Although late (too late?) I would
like to add my 2 cents worth.

My opinion is that
1. the best thing in APL are its IMPLICIT control structures.
2. adding EXPLICIT control structures are a danger because it invites
 programmers into scalar thinking (using loop instead of APL vectors
 and using IF's instead of masks, etc.). Yes, in this I agree with you
 Paul Mansour.
3. nevertheless even the most brilliant APL programmer needs explicit
 control sometimes (as B.Bernecky points out for I/O, memory
 restrictions, numeric programming etcetera).
4. when explicit control is needed, {->} (yes, I start liking your {..}
 proposal, Jim) is the worst thing to use. APL needs better explicit
 control structures.
5. although the need for explicit control structures is similar to
 that in 3d generation languages, the implementation should be in the
 "APL" way, not in the way those other languages have done (here I
 completely agree with Brian; brrrrrrrrr Manugistics!).

Shamelessly I submit that my proposal is elegant, KISS, and "APL-like".
I propose(d) an extension of the already existing control structure {->}.
That arrow should allow a dyadic use, as in "L{->}R" where R is
the control expression and L the expression to be controlled.
In "L{->}R"
-if R yields 0, L is not executed.                          \ IF construct
-if R yields 1, L is executed once.                         /
-if R yields n, L is executed n times                       > DO construct
-if R yields -n, L is executed n times and R is reevaluated > WHILE

Examples (just for illustration, not necessary realistic ones):
IF:   VAR{<-}DEFAULTVALUE {->} 0=[]NC 'VAR'
DO:       X{<-}SIMULATE X {->} ITER{<-}FINTIM {DIVIDE} STEPSIZE
WHILE:       V{<-}V,INPUT {->} - 0<{RHO}INPUT{<-}{QUOTEQUAD}
CASE:    sundayexpression {->} 1=DAY{<-}complicatedexpression
         mondayexpression {->} 2=DAY
                ...
         fridayexpression {->} 6=DAY
       saturdayexpression {->} 7=DAY

Yes, this can be nested:
   doexpression {->} condition3 {->} condition2 {->} condition1

Yes, this only works for small 1-line expressions. So complicated
things have to be "blocked" in a function. My preference would be to
extend the power of parenthesis (my paper in APL94; again shameless
adverti{*filter*}ts for my ideas) so they can act as a "blocking" mechanism
which would allow constructs like:
.....
.....
    ){->}condition
    expression1
    expression2
    ....
    (expression-n
....
....

Yes, this is technically easy to implement. We (actually Ryko Prins)
did that ten years ago in our APL\11 on out PDP11.

"This is a wonderfull proposal Eke" you might say, "but your CASE
example is not so elegant". Possibly. Extending the power of
parenthesis (APL94 again) might give a better CASE construct with a
vector of controlling numbers at the right and a vector of expressions
at the left. Like:
   (sundayexpression)(..)(..) .. (saturdayexpression) {->}DAY={IOT}7

For complicated expressions one could write:
.....
    ){->}DAY=1 2 3 4 5 6 7
     (sundayexpression)
     (mondayexpression)
         ...
     (fridayexpression)
    ((saturdayexpression)

Although I claim that the IF, DO , WHILE constructs with dyadic {->}
are powerfull, yet simple, elegant and relatively modest in its
strain upon the APL building, I must confess that I wonder if the CASE
construct needs more polishing (or replacement) by ideas from other, more
creative people.
After all, this a discussion forum for creative people.
Why don't you have a go at it?

Eke van Batenburg



Mon, 27 Jan 1997 20:27:40 GMT  
 Control structures in APL
I can't see why it is important that control structures are implemented
in "an APL Way"; surely the important thing is that they are implemented
in such a way that they become a valuable tool of thought. We have
struggled for 25 years without succeeding in finding productive ways to
describe explicit control structures or event-driven applications. Nobody
seems to object that we have borrowed the object-oriented paradigm for
event-drive code because it clearly simplifies the task, my feeling is
that the same is true for the way the traditional languages do explicit
control structures. After all, these control structures were probably the
feature which was uppermost in the mind of the early language designers.

I think they got it right, and I do not think we should consider the
control structures implemented by Manugistics and Iverson Software any
more part of the language than the GUI features, which also control the
flow of execution in a decidedly non-APL fashion.

The APL (or J) is just the algorithmic parts, which get dispatched by the
control structures / event handlers.

/ Morten Kromberg



Tue, 28 Jan 1997 05:55:09 GMT  
 Control structures in APL

Quote:

> Coming back from vacation it appeared that this forum had spawned a
> discussion about control structures. Although late (too late?) I would
> like to add my 2 cents worth.

Welcome back!  We really needed you...

Quote:
> My opinion is that
> 1. the best thing in APL are its IMPLICIT control structures.
> 2. adding EXPLICIT control structures are a danger...
> Shamelessly I submit that my proposal is elegant, KISS, and "APL-like".
> I propose(d) an extension of the already existing control structure {->}.
> That arrow should allow a dyadic use, as in "L{->}R" where R is
> the control expression and L the expression to be controlled.
> Yes, this can be nested:
>    doexpression {->} condition3 {->} condition2 {->} condition1

I'm interested in knowing how you would distinguish IMPLICIT from EXPLICIT.
Would "value-oriented" be a good criterion?

I assume you'd classify your dyadic -> as "explicit"; it is syntactically
and semantically "special".  For example, VAR <- EXPR -> COND is parsed
differently than one might expect.  It also may not produce any value.
There is no ELSE, so nested -> does not seem very handy to use.  Kind of
like ->(&+1)if~COND1 <> ->(&+1)if~COND2 <> ->(&+1)if~COND3 <> CODE where

failed, so may have to do them again.  I guess you chose CODE -> BOOLEAN
instead of the other way around (so-called "guarded commands" syntax) because
of the right-to-left evaluation of APL (am I right?).  I would still prefer
the other way though, in part because it would be more consistent with the
way the diamond <> separator works, i.e. left-to-right.

I think both <> and -> are "explicit" control structures.  Can we come up
with a new "implicit" one that is better?

Quote:
> Yes, this only works for small 1-line expressions. So complicated
> things have to be "blocked" in a function. My preference would be to
> extend the power of parenthesis (my paper in APL94; again shameless
> adverti{*filter*}ts for my ideas) so they can act as a "blocking" mechanism
> which would allow constructs like:
> .....
> .....
>     ){->}condition
>     expression1
>     expression2
>     ....
>     (expression-n
> ....
> ....

This seems problematic...  One has to parse matching () by eye to figure
out which line ends the block.  The multi-line CASE construct seems even
worse in this respect.  Redundant () should not so affect semantics; unlike
in LISP, () is not a "constructor" in APL.  Perhaps {} should be introduced
to the language?  (Sorry Jim :-)

Why not end the block with a leading ) at the end, _after_ expression-n?
Or use leading and/or trailing diamonds <> instead of )( ?

Quote:
> Yes, this is technically easy to implement. We (actually Ryko Prins)
> did that ten years ago in our APL\11 on out PDP11.

Ah, can I have the patches you made to APL\11?  As you may know, I've hacked
APL\11 a little so it understands APL! and the .keyword transliterations.

Quote:
> "This is a wonderfull proposal Eke" you might say, "but your CASE
> example is not so elegant". Possibly. Extending the power of
> parenthesis (APL94 again) might give a better CASE construct with a
> vector of controlling numbers at the right and a vector of expressions
> at the left. Like:
>    (sundayexpression)(..)(..) .. (saturdayexpression) {->}DAY={IOT}7

How about .. <> .. <> .. <> .. -> VECTOR?  (Or VECTOR -> .. <> .. <> .. <> ..)
For better or worse, strand notation is with us.

Quote:
> For complicated expressions one could write:
> .....
>     ){->}DAY=1 2 3 4 5 6 7
>      (sundayexpression)
>      (mondayexpression)
>          ...
>      (fridayexpression)
>     ((saturdayexpression)

> Although I claim that the IF, DO , WHILE constructs with dyadic {->}
> are powerfull, yet simple, elegant and relatively modest in its
> strain upon the APL building, I must confess that I wonder if the CASE
> construct needs more polishing (or replacement) by ideas from other, more
> creative people.
> After all, this a discussion forum for creative people.
> Why don't you have a go at it?

> Eke van Batenburg

I think the big obstacle is that APL is completely line-based.  To introduce
multi-line blocks (control structure), we need {}, which is of course not new!
Or < ... > (I think this can be done), and the diamond separator <> can be
seen as overstruck >< inside <..><..> .  But I am very uncomfortable with any
control structure that depends on rigid formatting cues (others might very
well disagree).  First we need to settle on blocks as a semantic construct
(right now a block is a line), then we can define conditional or repeated
execution, perhaps even achieve more implicit or value-based control.  This
may not be as easy to implement as Eke's or Manugistics', but as APL90 proves
it is certainly possible.

So, something like  {block1} {block2}  which generalizes  expr1 <> expr2
to nested blocks or to span several lines.  expr1 <> expr2  is equivalent to
{expr1} {expr2} (if we use <..> instead then <expr1> <expr2>).  Monadic
<- expr  can be used inside a block for returning one or more explicit values.
So,

if:       guard -> {block}
if-else:  guard -> {if-block} {else-block}  or  guard -> if-expr <> else-expr
case:     guard-vector -> {case1-block} {case2-block} etc.  (this is static)
for:      (count)?1 -> {block}  where ? is rho
while:    guard -> {block} <-  which I think is highly suggestive.

But is this a lost cause? :-)




Tue, 28 Jan 1997 06:19:15 GMT  
 Control structures in APL
Bill Chang:
.  if:       guard -> {block}
.  if-else:  guard -> {if-block} {else-block}  or  guard -> if-expr <> else-expr
.  case:     guard-vector -> {case1-block} {case2-block} etc.  (this is static)

I've always thought of if-else as corresponding to case with a default
action and only one selection (analogous to an iota/index construct).

Raul D. Miller             n =: p*q               NB. prime p, q, e

                           y =: n&|&(*&x)^:e 1
                           x -: n&|&(*&y)^:d 1    NB. 1 < (d*e) +.&<: (p,q)



Tue, 28 Jan 1997 06:34:12 GMT  
 Control structures in APL

Quote:
Raul Deluth Miller writes:
>Bill Chang:
>.  if:       guard -> {block}
>.  if-else:  guard -> {if-block} {else-block}  or  guard -> if-expr <> else-expr
>.  case:     guard-vector -> {case1-block} {case2-block} etc.  (this is static)

>I've always thought of if-else as corresponding to case with a default
>action and only one selection (analogous to an iota/index construct).

I see what you mean (or APL's default-less ->vector/labels).  That's certainly
one way to do it, single-selection.  Of course the case statement can have
a default block like if-else.  A more "syntactic" solution would be something
like

  case-expr ->
  :value1: {block1}
  :value2: {block2}
         : {default}

But as I said earlier, the basic question is whether APL should stick to lines
or broaden program control to nested blocks.  Both may be legitimate positions.
I get along fine with <> and my & (delta) style of simulating traditional
control.  In my opinion the Manugistics' approach is workable, though perhaps
inelegant.

Quote:
Morton Kromberg writes:
>I think they got it right, and I do not think we should consider the
>control structures implemented by Manugistics and Iverson Software any
>more part of the language than the GUI features, which also control the
>flow of execution in a decidedly non-APL fashion.

>The APL (or J) is just the algorithmic parts, which get dispatched by the
>control structures / event handlers.

I must disagree.  What is an algorithm if not well-specified control of
execution?  Are you saying -> (the traditional goto) is not part of the APL
language proper?  Or the use of dynamically scoped functions in APL?  
What about execute and each?  In my opinion, the specifics of the GUI features
may not be part of APL (yet), but the control flow via call-backs etc. is
certainly (going to be) part of the language.

Wish list:

Local functions, lambda expressions, or direct definition within a function.
(Same thing.)

Then the line oriented approach of APL would cease to be a limitation or gross
inconvenience.  Right now these are simulated using obfuscated execute, goto,

might help, to make the proliferation of trivial functions less painful, but
I sure would like to see a function stay self-contained if it is logically so!




Wed, 29 Jan 1997 06:13:58 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Proposal for control structures in APL

2. Proposal for control structures in APL

3. Proposal for control structures in APL (SAMSON)

4. Control Structures in APL

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. APL Control Structures

12. APL control structures -- new

 

 
Powered by phpBB® Forum Software