Control structures in APL
Author Message
Control structures in APL

Bill Chang suggests that a new control structure and a new blocking
mechanism could go hand in hand. A very good point indeed.
Instead of a separate symbol {->} for control and another
separate blocking symbol, one symbol should do it both.
In that case {->} is not very suitable; probably better is ":" (yes
Mr.Iverson, yes Mr.Chang, yes Mr.Jizba, yes Mr.Manugiustics, yes Mr...) or
{del} (yes Mr. Willhoft) or braces { } (yes Mr. C ).
In that case my examples change into:
{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
CASE:    {sundayexpression } 1=DAY<-complicatedexpression
{mondayexpression } 2=DAY
...
{fridayexpression } 6=DAY
{saturdayexpression } 7=DAY

{{{doexpression } condition3 } condition2 } condition1

.....
}condition yielding only 1 value (0, 1, n or -1)
expression1
expression2
....
{expression-n
....
....
{sundayexpression}{..}{..} .. {saturdayexpression}DAY=1 2 3 4 5 6 7

For complicated expressions one could write:
.....
}DAY=1 2 3 4 5 6 7
line 1 with sundayexpression
line 2 with mondayexpression
...
line 5 with thursday expression
line 6 with fridayexpression
{line 7 with saturdayexpression
.....

Multiline cases could be expressed as:
.....
}DAY=1 2 3 4 5 6 7
line 1 with sundayexpression
line 2 with mondayexpression
...
}
line 5a with thursday expression        3 lines to
line 5b with thursday expression        be executed
{line 5c with thursday expression       for DAY=5
line 6 with fridayexpression
{line 7 with saturdayexpression
.....

Pretty, is it not????

It still
- uses one symbol instead of keywords (the French will prohibit
Manugistics version 3 because it uses English! :-)
-has a condition at its right and the controlled expression at its
left . The reason is that APL programmers scan every expression from
right to left (except in case of those DD's (=Damned Diamonds). I like the
left-tag much more for assembling short related expressions in a line
than the diamond, but this is another discussion.
-has only one controlling symbol that does it all: IF, DO, WHILE
and IF/ELSE and CASE using a vector of controlling numbers.

Eke van Batenburg

PS. Bill Chang asks for the code of our dyadic {->} implementation in APL\11.
As we have no PDP/11 left now for many years, I do not have the
code that we programmed to implement this in APL/11. I will ask Ryko
Prins who did the actual coding. If you want, you can reach him by

PPS. Eke wrote

Quote:
>...the best thing in APL are its IMPLICIT control, but unfortunately we
>also need EXPLICIT control...
Bill:
>... what do you mean by implicit/explicit?

Sorry to confuse you and other readers. With IMPLICIT control I meant
"A+B" which performs a loop over all elements of A and B implicitly.
With explicit I meant the control that we as APL programmers have to
program explicitly, like (yes, indeed) {->} and <>.

Quote:

>The basic question is whether APL should stick
>to lines (and functions) or broaden program control to nested
>blocks....I get along fine with <>...

Yes Bill, I agree with you; you are quite right that this is a basic
question. If I look at published programs (to those in papers, to
those of my students as well as to my own programs) I see jumps all
over, which means that I see blocks all over.
So my answer is: EVERY APL PROGRAMMER NEEDS BLOCKS.

Quote:
Warren Vogt writes:
>...I am wary of this development because I fear it
>will lead to unidiomatic APL programs...

Yes Warren, you are right too. This can lure people in unidiomatic APL
programming.
On the other hand, look at your own programs. How many of your
programs are without jumps?
Every jump is also an indication that idiomatic APL falled short.
And each jump is also an indication that you needed a block/control
structure (which you had to program very clumsy because APL did not
provide you the proper tools).
So, yes your fears are real, but nevertheless we (you and me) need a
better blocking/control structure.

Quote:
PPPS. Mortan Kromberg writes:
>...Manugistics got it right...

I am glad they recognised the need for control structure and bit the bullet.
I am sorry for the unimaginative 3generationlike unKISS unAPL unsymbol
implementation.

Quote:
PPPS.{*filter*} Bowman writes:
>... Then along came Rob Willhofts proposal
>which seemed to make more sense the larger I looked at it.

Yes, I liked his proposal (which did blend nesting and control) too.
I only recoil from the increased complexity that Rob introduced with
it. What about a Bat-hoft or Will-tenburg combination where we take {DEL} and
{PYRAMID} for combined nesting and control and combine this with a control
at the right with 0/1,n,-n,vector for IF,DO,WHILE,CASE?
As an experiment, substitute {DEL} and {PYRAMID} for { and } in the above
examples. Do you need more power (and increased complexity)? I would
say this is a fine construct (what do you think Rob Willhoft?).
I would love if any APL producer would adopt either of those ideas.

...................................Eke van Batenburg

Sun, 02 Feb 1997 15:57:22 GMT
Control structures in APL
Eke van Batenburg:
.  -has a condition at its right and the controlled expression at its
.   left . The reason is that APL programmers scan every expression from
.   right to left (except in case of those DD's (=Damned Diamonds). I like the
.   left-tag much more for assembling short related expressions in a line
.   than the diamond, but this is another discussion.

When reading right to left, and top to bottom, it should be realized
that subsequent lines are logically to the left of the current line.
In other words,

A <- B + C) x D
R <- (

Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

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

Sun, 02 Feb 1997 23:52:22 GMT
Control structures in APL
Eke proposes eliding the -> symbol:

Quote:
>    {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

>    {{{doexpression } condition3 } condition2 } condition1

> .....
>     }condition yielding only 1 value (0, 1, n or -1)
>     expression1
>     expression2
>     ....
>     {expression-n
> ....
> ....
>    {sundayexpression}{..}{..} .. {saturdayexpression}DAY=1 2 3 4 5 6 7

> Multiline cases could be expressed as:
> .....
>      }DAY=1 2 3 4 5 6 7
>      line 1 with sundayexpression
>      line 2 with mondayexpression
>          ...
>         }
>         line 5a with thursday expression        3 lines to
>         line 5b with thursday expression        be executed
>         {line 5c with thursday expression       for DAY=5
>      line 6 with fridayexpression
>      {line 7 with saturdayexpression
> .....

> Pretty, is it not????

I think the flipping {}/}{ block delimiter is a real problem.

Is "else" to be notated {else}{if}(test), {if}{else}(test), or
{if}(test){else}?  What will code look like when if-else are nested
and span multiple lines?  Where does the "default" go, for "case"?

How about, try it out (or other schemes) on a few Toronto Toolkit functions?
The SS (string-search) functions seem like a nice group.

Quote:
> -has a condition at its right and the controlled expression at its
>  left . The reason is that APL programmers scan every expression from
>  right to left (except in case of those DD's (=Damned Diamonds). I like the
>  left-tag much more for assembling short related expressions in a line
>  than the diamond, but this is another discussion.

I have to admit that I like <> despite this "problem".  It is simply
a "virtual" line-feed.  Although it is here to stay (I think), interestingly
it was left out of the current "draft APL standard".

I thought the original justification for right-to-left _precedence_ was that
it made _reading_ left-to-right easier.  I mean, f of g of h etc.

Quote:

> >The basic question is whether APL should stick
> >to lines (and functions) or broaden program control to nested
> >blocks....I get along fine with <>...
> Yes Bill, I agree with you; you are quite right that this is a basic
> question. If I look at published programs (to those in papers, to
> those of my students as well as to my own programs) I see jumps all
> over, which means that I see blocks all over.
> So my answer is: EVERY APL PROGRAMMER NEEDS BLOCKS.

Okay.  The trouble with placing "control" to the right of a block, is
that it naturally falls to the end when the block spans several lines.
To move it back up, the block/control symbols become a bit confusing
(schizophrenic).

(Same problem with right-to-left evaluation in the first place--when a line
is wrapped it has to be read bottom-up, which is unnatural.  I believe this
factor keeps APL line-based, because blocks evolve from long lines.  Nial
is block-based therefore/because it is left-to-right.)

Quote:
> Warren Vogt writes:
> >...I am wary of this development because I fear it
> >will lead to unidiomatic APL programs...
> Yes Warren, you are right too. This can lure people in unidiomatic APL
> programming.

They'll soon pay for it in performance, so they'll learn, as we all did.
(Or they'll give up APL.)

Quote:
> PPPS.{*filter*} Bowman writes:
> >... Then along came Rob Willhofts proposal
> >which seemed to make more sense the larger I looked at it.
> Yes, I liked his proposal (which did blend nesting and control) too.
> I only recoil from the increased complexity that Rob introduced with it.

I found it overly complex/rigid...  (A minor point is that using {DEL} and
{DELTA} will make ASCII transliteration even uglier; Willhoft does suggest
several alternatives.)

Quote:
> ... Do you need more power (and increased complexity)? I would
> say this is a fine construct (what do you think Rob Willhoft?).
> I would love if any APL producer would adopt either of those ideas.

I think it needs more work, just like all other proposals :-( :-)

p.s. wish I could discuss this subject with all of you at APL94 :-(

Mon, 03 Feb 1997 00:19:49 GMT
Control structures in APL
Kim Whitelaw makes a very natural and attractive proposal, elevating a block
to (scalar) first-class status.  Control then becomes "implicit".  A month
ago Brian McGuinness made a similar proposal:

Quote:
>introduce a new APL data type consisting of an "enclosed" executable
>expression.  This might be represented by enclosing the expression in braces,

>"disclose" such expressions, causing them to be evaluated.  This approach
>would allow the full power of APL's data selection capabilities to be utilized
>in selecting expressions to be executed.

And I'm sure others have thought of it before.  The difficulty is
implementation, and the can-of-worms that comes with funargs, closures,
scoping rules, etc. (as has been discussed recently).  Realistically,
blocks cannot (yet) become "referentially transparent" first-class objects.
Nevertheless, {} and generalized execute might give APL an elegant control
structure.  One way to look at it, is that a block {...} really is just a
"scalarized" string '...', and if used out-of-context may give unexpected
or erroneous results.  Then the following should work:

(Kim Whitelaw)

Quote:
>IF:  (0=[]NC 'VAR') execute {VAR<-DEFAULTVALUE}
>DO:  (ITER<-floor FINTIM divide STEPSIZE) execute {X<-SIMULATE X}
>WHILE: {0 < rho INPUT<-quotequad} execute {V<-V,INPUT}
>CASE: execute ((iota 7) element DAY<-EXPRESSION)/{MONDAYEXPRESSION} {TUESDAYEXPRESSION}...{SATURDAYEXPRESSION}
>IF-THEN-ELSE:  execute (1 0=BOOLEAN)/{THEN_EXPRESSION} {ELSE_EXPRESSION}

I would suggest that this form of execute always be dyadic, so the interpreter
doesn't have to worry about mixed or unknown types (block or string).  And,
what's inside a block cannot be manipulated because a block is scalar.
I think, what remains to be resolved is breaking lines.  If a block cannot
span several lines, one will have to write:

THEN_EXPR<- {...}
ELSE_EXPR<- {...}
MON_EXPR<- {...}
TUE_EXPR<- {...}
...
SUN_EXPR<- {...}
DEFAULT<- {...}

IF:    1 execute (1 0=test)/THEN_EXPR ELSE_EXPR
CASE:  1 execute ((iota 7) iota expr)/MON_EXPR TUE_EXPR ... SUN_EXPR DEFAULT

where each of the "direct definitions" may require many other definitions.
(No, not the dreaded THEN_EXPR<- THEN_EXPR, {...} !)  This style is close to
the "let" construct in some classical functional-programming languages, which
also include a "where" construct, ...EXPR... where EXPR is ... , for both
readability and writability.  Without "where", it is probably better to
allow blocks to span several lines.

I'm not sure how useful N execute {...} really is--it appears equivalent
to 1 execute N/{...} etc.  It may be better to do what Raul Deluth Miller
has suggested, use the left numerical argument for indexing or selecting

Another approach, is the BASIC GOSUB :-)  Inside a function, direct definitions
(blocks) can be written as

NAME: ...
...
...
<-               or :NAME or just : to end a block

They are then "called" with a _dyadic_ goto or execute.  Perhaps arguments
can be passed via the left argument.

p.s. In my APL! transliteration scheme, a distinction is made (automatically
by the parser) between purely ASCII literal strings and those that contain
APL symbols.  The former are enclosed in "..." instead of '...' so punctuation
marks like ? ! * will not be incorrectly (un)translated.  If APL code inside
quotes could somehow be detected as such, then enclosing them in {} instead of
' ' would be a real win both for readability and potential optimization.
Take a look at the Toronto Toolkit in APL!, available by anonymous ftp from
cshl.org, directory pub/bill/apl.

Mon, 03 Feb 1997 06:19:58 GMT
Control structures in APL
Bill Chang:
.  I thought the original justification for right-to-left _precedence_
.   was that it made _reading_ left-to-right easier.  I mean, f of g of
.  h etc.

Ok, and if this is extended to a multiple-physical-line equals
one-logical-line design, then the logical implication would be that
the last line of a function is executed first.

--
Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

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

Mon, 03 Feb 1997 06:39:53 GMT
Control structures in APL
WC>  And I'm sure others have thought of it before.

Yes.  Look at the papers dealing with "function arrays" or "gerunds".
There'll be an entire tutorial "TAGS - Trains, Agendas, and Gerunds"
by Iverson and Hui at APL94.  As for

WC>  The difficulty is implementation...

take a look at J, where you can do exactly what you described in your
example.

Martin Neitzel

Mon, 03 Feb 1997 20:35:17 GMT
Control structures in APL

Quote:
>Kim Whitelaw makes a very natural and attractive proposal, elevating a block
>to (scalar) first-class status.  Control then becomes "implicit".  A month
>ago Brian McGuinness made a similar proposal:

>>introduce a new APL data type consisting of an "enclosed" executable
>>expression.  This might be represented by enclosing the expression in braces,

>>"disclose" such expressions, causing them to be evaluated.  This approach
>>would allow the full power of APL's data selection capabilities to be utilized
>>in selecting expressions to be executed.

Yup. Check out my APL84 paper "Function Arrays", [ACM SIGAPL QUote Quad,
Vol 14, no 4, 1984], which discussed both of these ideas, and suggested
an extension to execute which is similar to some of the recent postings
here.

What was not in Function Arrays was any iterative control structure
capability. The "Apply" extension to execute, combined with selection
verbs, gave simple IF/then/else and CASE capability.

Bob

Mon, 03 Feb 1997 21:48:04 GMT
Control structures in APL

Quote:
>Bill Chang:
>.  I thought the original justification for right-to-left _precedence_
>.   was that it made _reading_ left-to-right easier.  I mean, f of g of
>.  h etc.

>Ok, and if this is extended to a multiple-physical-line equals
>one-logical-line design, then the logical implication would be that
>the last line of a function is executed first.

Raul, are you suggesting this would be a good thing?

I think, the right-to-left argument applies only to a single phrase.
That is, it makes _left-to-right reading_ of a single phrase easier or
more "functional".  It certainly does not apply to ordering several
phrases, which should be read the "normal" way as in conventional
natural or formal languages.

Thus, lines are still top-to-bottom.  (Otherwise one would not know
where to start!)  The <> separates a line into phrases, which are also
read in the "normal" order.  The "left-tack" reverses the order of
reading/evaluating separate phrases; to me, it messes up the logic
behind the right-to-left argument.

Quoting Iverson:
An expression _evaluated_ from right to left is the easiest to _read_
from left to right.  For example, the expression
a + x * b + x * c + x * d + x * e + x * f             [ * is times ]
(for the efficient evaluation of a polynomial) is read as a plus the
entire expression following, or as a plus x times the following expression,
or as a plus x times b plus the following expression, and so on.
("Conventions governing order of evaluation", A Source Book in APL, pp 31-32)

Anyway, an if/case expression can look like

(control) execute {
{ case1-line1 }                           o} redundant {} are fine
case1-line2-phrase1 <> phrase2
(test) execute { if-statement }{ else-statement }
(test) execute { if-statement }
(test) execute { if-statement }{          o} open trailing { indicates
else-line1                             o} continuation on next line
else-line2 }                           o} trailing } closes if-else

Quote:
}{ case2-line1
case2-line2
}{ case3 }{
default-case
}

where a closing } not immediately followed by an open { _on the same line_
ends a control structure.  Indentation and most line-breaks are flexible!

Mon, 03 Feb 1997 22:04:11 GMT
Control structures in APL

Quote:
>Yup. Check out my APL84 paper "Function Arrays", [ACM SIGAPL QUote Quad,
>Vol 14, no 4, 1984], which discussed both of these ideas, and suggested
>an extension to execute which is similar to some of the recent postings
>here.

>What was not in Function Arrays was any iterative control structure
>capability. The "Apply" extension to execute, combined with selection
>verbs, gave simple IF/then/else and CASE capability.

While more powerful, "Function Arrays" did not include a delimited block
structure, which is very much needed for readability and writability, and
what we seem to be focusing on right now.  J and its precursors have always
had some of the neat stuff, but it is unrealistic to expect current APL
(exclusive of J) implementors to add first-class functions etc. at this point.
Perhaps an elegant control/block structure can be added at much lower cost.

There seem to be several paths:
(1) line-based direct definition within a function
(a) function assignment which must occur prior to use
(b) GOSUB to a labelled block which can be anywhere
(c) implicit or explicit parameters, or none at all?
(2) multi-line, nestable, delimited block
(a) at the statement level, keyword/symbol at beginning of line
(b) at the statement level, more flexible syntax
(c) at the expression level, i.e. can appear anywhere
(d) implicit or explicit execute/apply?

Right now, I lean toward 2b explicit, possibly combined with 1b explicit.
I think the alternatives require greater stylistic change or implementation
effort.

What do you think?

Mon, 03 Feb 1997 23:57:54 GMT
Control structures in APL

Quote:

>>Yup. Check out my APL84 paper "Function Arrays", [ACM SIGAPL QUote Quad,
>>Vol 14, no 4, 1984], which discussed both of these ideas, and suggested
>>an extension to execute which is similar to some of the recent postings
>>here.

>>What was not in Function Arrays was any iterative control structure
>>capability. The "Apply" extension to execute, combined with selection
>>verbs, gave simple IF/then/else and CASE capability.

>While more powerful, "Function Arrays" did not include a delimited block
>structure, which is very much needed for readability and writability, and
>what we seem to be focusing on right now.  J and its precursors have always

Absolutely correct. Closely related to this is my desire for
local functions which are statically defined, rather than baving to be
invented on the fly with quadfx, etc., with double quoting and other
syntactic ugliness.

Quote:
>had some of the neat stuff, but it is unrealistic to expect current APL
>(exclusive of J) implementors to add first-class functions etc. at this point.

I agree. I'm wondering if it's time to abandon APL and replace
it with something new, like an industrial-strength J.
APL is too hard to extend anymore, and the lack of cooperation among
vendors in terms of REAL standardization [ By which I mean:
I can write an application to an operating system file from one APL
, read it into another APL, and have it run correctly]
is just another nail in the APL coffin.

Quote:
>Perhaps an elegant control/block structure can be added at much lower cost.

>There seem to be several paths:
>(1) line-based direct definition within a function
>    (a) function assignment which must occur prior to use
>    (b) GOSUB to a labelled block which can be anywhere
>    (c) implicit or explicit parameters, or none at all?
>(2) multi-line, nestable, delimited block
>    (a) at the statement level, keyword/symbol at beginning of line
>    (b) at the statement level, more flexible syntax
>    (c) at the expression level, i.e. can appear anywhere
>    (d) implicit or explicit execute/apply?

>Right now, I lean toward 2b explicit, possibly combined with 1b explicit.
>I think the alternatives require greater stylistic change or implementation
>effort.

I prefer nesting at the statement level. Apply has its place,
but like execute, is NOT a substitute for clean design.

Bob

Tue, 04 Feb 1997 03:55:15 GMT
Control structures in APL
>Ok, and if this is extended to a multiple-physical-line equals
>one-logical-line design, then the logical implication would be
>that the last line of a function is executed first.

William Chang:
Raul, are you suggesting this would be a good thing?

I think, the right-to-left argument applies only to a single
phrase.  That is, it makes _left-to-right reading_ of a single
phrase easier or more "functional".  It certainly does not apply to
ordering several phrases, which should be read the "normal" way as
in conventional natural or formal languages.

That's fine for a system where each line is a distinct phrase.
However, it becomes nonsensical when phrases can span multiple lines.

If phrases can span multiple lines it becomes important to use the
same logical ordering rules to order lines as are used to organize
within a line.

This doesn't imply a lot about the grammar of control structures,
since control structures should be used with a syntax that defers
execution of arguments (either indefinitely, or until after the
control phrase has been evaluated).  Perhaps something like

R <- (controlphrase) selects
phrase0 `
phrase1 `
phrase2 `
defaultphrase

By the way, in my opinion: if APL control structures are "done right"
it should be possible for users to roll their own variants.

--
Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

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

Thu, 06 Feb 1997 19:20:43 GMT
Control structures in APL

Quote:

>    >Ok, and if this is extended to a multiple-physical-line equals
>    >one-logical-line design, then the logical implication would be
>    >that the last line of a function is executed first.
> William Chang:
>    Raul, are you suggesting this would be a good thing?
>    I think, the right-to-left argument applies only to a single
>    phrase.  That is, it makes _left-to-right reading_ of a single
>    phrase easier or more "functional".  It certainly does not apply to
>    ordering several phrases, which should be read the "normal" way as
>    in conventional natural or formal languages.

> That's fine for a system where each line is a distinct phrase.
> However, it becomes nonsensical when phrases can span multiple lines.
> If phrases can span multiple lines it becomes important to use the
> same logical ordering rules to order lines as are used to organize
> within a line.

I'm not sure I agree with this.  The right to left order of evaluation
follows from a desire to be able to easily read from left to right.  To
use terminology from language, the first verb encountered in a left to
right scan of the sentence identifies the meaning (value) of the sentence.
Other phrases are subordinate and their meaning must be determined first.

When dealing with several clauses in a sentence, each which produces
a value, APL syntax prescribes the manner in which these values are
to be composed to produce a single value for the entire sentence.  The
situation when dealing with several sentences (a paragraph) is different.
The values resulting from each sentence are not combined into a single
value for the entire paragraph.  It seems to me to make more sense
to do these in left to right (top to bottom) order since that is
the way each sentence is read.  Particularly, considering side effects
(assignments), it seems very cumbersome to enumerate these in reverse order.

- Show quoted text -

Quote:
> This doesn't imply a lot about the grammar of control structures,
> since control structures should be used with a syntax that defers
> execution of arguments (either indefinitely, or until after the
> control phrase has been evaluated).  Perhaps something like
>    R <- (controlphrase) selects
>             phrase0 `
>             phrase1 `
>             phrase2 `
>             defaultphrase
> By the way, in my opinion: if APL control structures are "done right"
> it should be possible for users to roll their own variants.
> --
> Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

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

--
________________________________________________________________________

Computer Science Department     telephone: (210) 736-7480
Trinity University              fax:       (210) 736-7477

Fri, 07 Feb 1997 05:12:58 GMT
Control structures in APL
John E. Howland:
.  I'm not sure I agree with this.  The right to left order of
.  evaluation follows from a desire to be able to easily read from
.  left to right. ...

Seems to me that the same logic indicates that a bottom to top order
of evaluation would follow from a desire to be able to easily read
from top to bottom.

Consider an expression of the form

clause a
where
clause b
clause c
clause d

Here, 'clause a' is the heart of the matter.  However, ANSI APL would
typically relegate it to line [19] or some such.

.  Particularly, considering side effects (assignments), it seems very
.  cumbersome to enumerate these in reverse order.

You mean like   a <- d x b + c <- d ?

You may have a point here, but I'm not sure I agree with it in this
context.

--
Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

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

Fri, 07 Feb 1997 11:03:36 GMT
Control structures in APL

Quote:
>John E. Howland:
>.  I'm not sure I agree with this.  The right to left order of
>.  evaluation follows from a desire to be able to easily read from
>.  left to right. ...

>Seems to me that the same logic indicates that a bottom to top order
>of evaluation would follow from a desire to be able to easily read
>from top to bottom.

>Consider an expression of the form

>   clause a
>where
>   clause b
>   clause c
>   clause d

>Here, 'clause a' is the heart of the matter.  However, ANSI APL would
>typically relegate it to line [19] or some such.

Some classical functional-programming languages indeed use the "where"
form; however, it doesn't matter how the "wheres" are arranged because
they are side-effect free, i.e. temporary names not true assignments.
Indeed, for things written in the "functional" style, the "where" form
is easier to read (top-to-bottom, left-to-right) than the "let" form.

Quote:
>.  Particularly, considering side effects (assignments), it seems very
>.  cumbersome to enumerate these in reverse order.

>You mean like   a <- d x b + c <- d ?

Broken up into two lines, inside a loop for example.  Within a line
(ignoring <>), APL is somewhat "functional".  However APL becomes very
"imperative" across lines, with lots of side-effects, branches and loops.
I don't see how these can be evaluated "bottom-to-top".

Re: block and goto
Suppose we have a delimited, nestable, multi-line block structure with
associated control elements.  What should be the "extent" of a label?
I think it should be the block in which the label is defined, including
nested sub-blocks but not super-blocks.  A label at the bottom of a loop
block can be used for "continue" (i.e. go to next iteration).  A label
just outside a loop block can be used for "break" (i.e. go out of loop).

Re: "control structure"
How is this term usually defined?  Seems to me that it must refer to a block
of code plus a control.  A "goto" is a control statement but not a program
_structure_; the code between the goto and the destination label or some
such is the "control structure", properly speaking.  APL's control structures
include workspace, function, line, higher-order primitives ("operators") and
of course the array data structure itself.

Re: roll your own control structures
I think this is what people don't want to see occur again :-)

Sat, 08 Feb 1997 01:08:42 GMT
Control structures in APL

Quote:

>>While more powerful, "Function Arrays" did not include a delimited block
>>structure, which is very much needed for readability and writability, and
>>what we seem to be focusing on right now.  J and its precursors have always

>Absolutely correct. Closely related to this is my desire for
>local functions which are statically defined, rather than baving to be
>invented on the fly with quadfx, etc., with double quoting and other
>syntactic ugliness.

Not only statically defined, but real, statically _scoped_ local functions!
(We can dream a little :-)  Lexical inclusion of local functions (when
appropriate and important) can make things simpler (such as compiling)
and more powerful as well.

Quote:
>>had some of the neat stuff, but it is unrealistic to expect current APL
>>(exclusive of J) implementors to add first-class functions etc. at this point.

>I agree. I'm wondering if it's time to abandon APL and replace
>it with something new, like an industrial-strength J.
>APL is too hard to extend anymore, and the lack of cooperation among
>vendors in terms of REAL standardization [ By which I mean:
>I can write an application to an operating system file from one APL
>, read it into another APL, and have it run correctly]
>is just another nail in the APL coffin.

Sigh.

Maybe, just maybe, Manugistics has just forced the rest of them to come
together and define an alternative common control structure etc. (Dream on.)
Maybe they'll even learn from this thread (ha).

Quote:
>>Perhaps an elegant control/block structure can be added at much lower cost.

>>There seem to be several paths:
>>(1) line-based direct definition within a function
>>    (a) function assignment which must occur prior to use
>>    (b) GOSUB to a labelled block which can be anywhere
>>    (c) implicit or explicit parameters, or none at all?
>>(2) multi-line, nestable, delimited block
>>    (a) at the statement level, keyword/symbol at beginning of line
>>    (b) at the statement level, more flexible syntax
>>    (c) at the expression level, i.e. can appear anywhere
>>    (d) implicit or explicit execute/apply?

>>Right now, I lean toward 2b explicit, possibly combined with 1b explicit.
>>I think the alternatives require greater stylistic change or implementation
>>effort.

>I prefer nesting at the statement level. Apply has its place,
>but like execute, is NOT a substitute for clean design.

Yes I think there is danger in proposing too much.  Over the years many
grand proposals have come forth, for solving this problem and then tons
others at the same time.  A solution can be _too_ general, and will be
ignored!

Sat, 08 Feb 1997 01:32:55 GMT

 Page 1 of 2 [ 25 post ] Go to page: [1] [2]

Relevant Pages