Control Structures in APL 
Author Message
 Control Structures in APL

Bill Chang has asked for more input from the other 99%, so here goes.

I think J is showing the way (or was): operators as control
structures, along with function assignment and  "nonce functions",
(using { and } as delimiters for APL) and function arrays (gerunds).
I don't see why we can't put this functionality in APL2. A lot of it
is already in Dyalog APL.
So we have some inconsistencies; we can think about them for
another 20 years.

With these in place, the operater-style control structures can allow
for multiple, parallel, independent "function" execution, based on
possible *vector* controls. This seems much more "APL-ish" than
control words.

I say "or was" because J has recently introduced some reserved-word
control words that look a lot like the ones in APL*III (I haven't
used the J versions).

I have three problems with this (APL*III)
1) *english* reserved words (redefinable in J?)
2) *scalar* controls
3) I see examples like the following in the code distributed with APL*III
  (in the TUTORIAL WS, presumably written for tutorial purposes):
  5 :if t>c
  6  t<-c
  7 :endif
  What is wrong with:
      t<-t{lesser}c
  Takes less space, easier to read, works with any conformable arrays.
  In fact, it's APL, whereas the tutorial example is not.
  In some earlier post, someone worried that the tutorial type of
  coding might result from introducing these structures. S/he was right.

There are a *number* of nice things about APL*III, in particular the
editor, which allows double-clicking on a *name*, which then puts you
in function/variable definition mode for the object with that name.
Exiting from this definition puts you back where you were, which might
be editing a function that uses this sub-function.
This would fit in very nicely with the definition of small
sub-functions that show up so often with the operater-as-control-
structure paradigm...if only APL*III had operators.

Finally, there was some talk about extending {execute} to act as a
control structure in its dyadic form. This would be a mistake for a
number of reasons, most obvious being the proliferation of ''...''...''

I'd much rather see dyadic {execute} as a true inverse of dyadic
{format}, in particular dyadic format by example. It would sure make
it a lot easier to read an ASCII file with embedded newlines, tabs,
etc, and would give APL the power of the fortran formatted READ
statement. It would also result in less writing of FSMs, and less need
for the control words being discussed.

Just my 2c<bs>| worth. Now for you other 98%...




Thu, 20 Feb 1997 05:55:06 GMT  
 Control Structures in APL

Quote:

>Bill Chang has asked for more input from the other 99%, so here goes.
>I think J is showing the way (or was): operators as control
>structures, along with function assignment and  "nonce functions",
>(using { and } as delimiters for APL) and function arrays (gerunds).
>I don't see why we can't put this functionality in APL2. A lot of it
>is already in Dyalog APL.
>So we have some inconsistencies; we can think about them for
>another 20 years.

If you (or someone else) can write up a concise proposal that fits
on a page or slide, perhaps we and the community at large can think
about it.

Quote:
>There are a *number* of nice things about APL*III, in particular the
>editor, which allows double-clicking on a *name*, which then puts you
>in function/variable definition mode for the object with that name.
>Exiting from this definition puts you back where you were, which might
>be editing a function that uses this sub-function.
>This would fit in very nicely with the definition of small
>sub-functions that show up so often with the operater-as-control-
>structure paradigm...if only APL*III had operators.

Is the proliferation of small sub-functions in this style of programming
likely to pose a serious problem?

Quote:
>Finally, there was some talk about extending {execute} to act as a
>control structure in its dyadic form. This would be a mistake for a
>number of reasons, most obvious being the proliferation of ''...''...''

It would only make sense if {...} is substituted for the dreaded quotes.

Quote:
>Now for you other 98%...

Thanks!




Sat, 22 Feb 1997 22:51:42 GMT  
 Control Structures in APL

Quote:

>>I think J is showing the way (or was): operators as control
>>structures, along with function assignment and  "nonce functions",
>>(using { and } as delimiters for APL) and function arrays (gerunds).

         ^^^^^^^                                      
[#delta a bunch of line numbers]

Quote:
>>There are a *number* of nice things about APL*III, in particular the
>>editor, which allows double-clicking on a *name*, which then puts you
>>in function/variable definition mode for the object with that name.
>>Exiting from this definition puts you back where you were, which might
>>be editing a function that uses this sub-function.
>>This would fit in very nicely with the definition of small
>>sub-functions that show up so often with the operater-as-control-
>>structure paradigm...if only APL*III had operators.
>Is the proliferation of small sub-functions in this style of programming
>likely to pose a serious problem?

I often find it useful to create a small sub-function to replace a
bunch of #each's (for example). About 50% of the time, I would be
just as happy to write (dumb example follows):
{w#iota #floor/w} #each #enclose[2] ...
where w is omega, and the { and } are delimiters for the anonymous
"nonce function". That's one place where these would come in handy,
and they seem to correspond to J's tacit functions.
(Here I'm more-or-less following Phil Benkard's paper, with some
follow-up suggestions -- don't have the references at hand).

In other cases, it would be more useful to define a seperate function, when
a) it's not dead obvious what is being done and a few comments would help
b) the "function" might be generally useful in other contexts
c) the definition is rather long (I like to keep everything visible)
d) multiple lines (or diamonds) or loops or recursion are required for
   whatever reason

Quote:
>>Finally, there was some talk about extending {execute} to act as a
>>control structure in its dyadic form. This would be a mistake for a
>>number of reasons, most obvious being the proliferation of ''...''...''
>It would only make sense if {...} is substituted for the dreaded quotes.

I agree! (see begining of repost)

[{delta} a bunch more line numbers]



Mon, 24 Feb 1997 05:25:31 GMT  
 Control Structures in APL

Quote:

>I often find it useful to create a small sub-function to replace a
>bunch of #each's (for example). About 50% of the time, I would be
>just as happy to write (dumb example follows):
>{w#iota #floor/w} #each #enclose[2] ...
>where w is omega, and the { and } are delimiters for the anonymous
>"nonce function". That's one place where these would come in handy,
>and they seem to correspond to J's tacit functions.

It seems that one can write 'w #iota #floor/w' MONAD #each ... where
MONAD is an _operator_ that either fixes the string or simply executes
it after substituting out the w.




Mon, 24 Feb 1997 06:27:08 GMT  
 
 [ 4 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