Control structures; discussion or proposal 
Author Message
 Control structures; discussion or proposal

Raul Miller gives a nice survey of wishes that are mostly solved by a
proper constrol structure in APL. I would like to add:

H. I often read APL programs of others where flow goes from everywhere
  to everywhere (the infamous spagetti flow). Sometimes (sure, not
  always) very hard to determine on which conditions a certain part
  of the program is executed and where to place my addition. If
  structured control was available, we could teach programmers to
  think/design structural instead of flowing.

...................................................

Quote:
Bill Chang writes:
>To be honest, I think it is impossible to come to "consensus" on a
>controversial subject on apl-l or c.l.a.  Mailing lists or Usenet newsgroups
>simply do not foster that kind of goal.  People drift in and out of
>discussions, voice their opinion when they have time or inclination, but
>generally keep silent (i.e. NOT VOTING).  Very few people (can) spend the
>effort to follow-up, or to back up their opinions when "challenged".
>...However, I find it a great help _to me_ to hear different opinions, so
>I can form _my own_ "synthesis".

Ok, Bill. There is nothing wrong with that. But the problem is that
this discussion has been going on for more than 15 years and it has
nothing yielded except a wide variety of attractive ideas (...oh yes,
also a very uninspired implementation by Manugistics that tried to
ignore all of those ideas completely).

I have the feeling that one important reason that implementers did
not catch up with any of these attractive ideas is because everybody
proposes something different. Maybe I am wrong.
Probably I am also naive in thinking that we could get a concensus.
But in my view this is the only thing that can stimulate APL producers
to bite the bullet.

Quote:
Sam Sirlin writes:
>... We have very little influence on what IBM or Manugistics does.

Yes, Sam, we have no control over them.
But don't you think that if the APL community agreed on a proposal
(don't laugh, please) and said "WE WANT....." and added meekly "please"
this would influence them more then all different proposals?
Are you so callous to refuse such a plea Mr.IBM, Mr.Dyalog, Mr.68000
(are you Jim, Peter, David?)

So I would like to have an effort that really comes to something.
And as I see it currently the only way to come to something is (apart
from seducing or bribing some of the APL developers (...Oh yes, how much
money would it cost? maybe this is the way )) to come to a
(relatively) broadly supported proposal.

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



Mon, 17 Feb 1997 19:29:28 GMT  
 Control structures; discussion or proposal
Eke van Batenburg:
.  H. I often read APL programs of others where flow goes from
.    everywhere to everywhere (the infamous spagetti flow). Sometimes
.    (sure, not always) very hard to determine on which conditions a
.    certain part of the program is executed and where to place my
.    addition. If structured control was available, we could teach
.    programmers to think/design structural instead of flowing.

Um... control structures won't really solve this problem.  They could
make it worse.

There're several reasons for awful code structure: poor programmer,
ugly design requirement, or many programmers maintaining the code over
a period of time -- or possibly it's a problem with the reader.  In
general, hard to read code is a red-flag indicating something needs
attention.

Control structures could make code harder to read if they're applied
to "the wrong problems".  E.g. if they replace simple array
manipulations with something more baroque.  This isn't a reason to
avoid the introducing the structures, however.

Trivial example of potential "harder to read code":

R{gets}X{take}Y

vs.

SHY{gets}{rho}Y
R{gets}X<SHY{if}X{rho}Y{else}Y,(SHY-X){rho}0{then}

or

SHY{gets}{rho}Y
X<SHY{if}
 R{gets}X{rho}Y
{else}
 R{gets}Y,(SHY-X){rho}0
{then}

For many cases, these are equivalent code.  For those which are not,
it might be instructive to also consider a more elaborate form which
replaced the 0 with an expression which computes the appropriate fill
element.

--
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, 17 Feb 1997 20:39:13 GMT  
 Control structures; discussion or proposal

Quote:
>H. I often read APL programs of others where flow goes from everywhere
>  to everywhere (the infamous spagetti flow). Sometimes (sure, not
>  always) very hard to determine on which conditions a certain part
>  of the program is executed and where to place my addition. If
>  structured control was available, we could teach programmers to
>  think/design structural instead of flowing.

I would guess, that a simple if-then-else block would alleviate this problem
tremendously.  I.e., most of the labels and gotos are if-then-else rather
than loops.  The problem is that visually they are indistinguishable so the
combination looks like spagetti.  Right now APLers are forced to write code
that is/appear flow-oriented because there is no if-then-else (blocks).

Quote:
>I have the feeling that one important reason that implementers did
>not catch up with any of these attractive ideas is because everybody
>proposes something different. Maybe I am wrong.

I'm not sure that _any_ of the previous proposals can be considered truly
elegant ("simple and surprisingly effective").  Attractive ideas do not
necessarily make good proposals.  Everybody proposes something different
because nothing yet works.

Quote:
>Probably I am also naive in thinking that we could get a concensus.

There are at least a couple hundred people reading this, but 99% keep
silent.  The best we can do is a consensus of two or three or four people.

Quote:
>But in my view this is the only thing that can stimulate APL producers
>to bite the bullet.

If a truly simple proposal (one slide) is shown at APL94 and the audience
supports it overwhelmingly, maybe.  Another problem with Minnowbrook is
that the users are missing.

Quote:
>But don't you think that if the APL community agreed on a proposal
>(don't laugh, please) and said "WE WANT....." and added meekly "please"
>this would influence them more then all different proposals?
>Are you so callous to refuse such a plea Mr.IBM, Mr.Dyalog, Mr.68000
>(are you Jim, Peter, David?)

Jim, Peter, David, will you say publicly that you would seriously consider
such a proposal?

Quote:
>So I would like to have an effort that really comes to something.
>And as I see it currently the only way to come to something is (apart
>from seducing or bribing some of the APL developers (...Oh yes, how much
>money would it cost? maybe this is the way )) to come to a
>(relatively) broadly supported proposal.

I think it will have to be a modest proposal (I really hate to say that).
Something like a simple if-then-else nested block, or perhaps a GOSUB.




Mon, 17 Feb 1997 22:45:52 GMT  
 
 [ 3 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. How to code a discussion-forum? (tree structure)

5. ANSI X3J14 Forth Technical Proposal (Data Structure)

6. PROPOSAL: New Control Flow Words

7. Espace de discussion Python francophone / French speaking place for Python discussions

8. Control Structure Question

9. More control structures

10. Control Structures in APL

11. Control Structures in APL

12. Control structures in APL

 

 
Powered by phpBB® Forum Software