Proposal for control structures in APL 
Author Message
 Proposal for control structures in APL

Bill Chang proposes:

Quote:
>Perhaps, we on c.l.a. should try to come to a consensus first or at least
>a small number of clearly stated positions, which can then be presented
>or "voted on" at APL94.  If we can't do that in however many weeks, it's
>not likely to be resolved in a few hours face-to-face...

I too have my doubts if it is possible to come to a common proposal in
one session.
I have even more doubts about that through e-mail.
In face-to-face contacts there are established ways to recognise the
way others feel about particular things; his face (if someone turns
red we are really talking about something important), his voice
(raised to a thrill pitch must mean he is not joking) etc. But how
do you measure in e-mail whether someone just made a whimsical remark
or has a very fierce position about something?
The above might look like joking, but I am really serious. How can you
come to a common proposal by e-mail, I wonder. Does anyone has
experience? You Bill?

I am willing to try such an e-mail discussion if I could be
convinced that it is possible. We wouldn't be forced to compress that in
one or two weeks before APL94; a well supported proposal in APL95 is
nice enough in my view. Maybe initiated in an APL94 session.
But is this feasable?

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



Sat, 15 Feb 1997 15:47:30 GMT  
 Proposal for control structures in APL


: I am willing to try such an e-mail discussion if I could be
: convinced that it is possible. We wouldn't be forced to compress that in
: one or two weeks before APL94; a well supported proposal in APL95 is
: nice enough in my view. Maybe initiated in an APL94 session.
: But is this feasable?

It might be encouraging to consider what the linux community has
accomplished through the net.  Those unaware of the linux effort might
look at the "Linux Meta FAQ" and "Linux Specification Sheet" that are
among the periodic postings to comp.os.linux.announce, comp.answers,
news.answers, and archived at rtfm.mit.edu and other places.  Not to
cause a digression but for example of a large complex effort with many
controversial issues that has been not only successfully conducted on
the net but that probably could not have been done otherwise.

--jam



Sat, 15 Feb 1997 20:26:47 GMT  
 Proposal for control structures in APL

Quote:
Eke writes:

> Bill Chang proposes:
> >Perhaps, we on c.l.a. should try to come to a consensus first or at least
> >a small number of clearly stated positions, which can then be presented
> >or "voted on" at APL94.  If we can't do that in however many weeks, it's
> >not likely to be resolved in a few hours face-to-face...

> I too have my doubts if it is possible to come to a common proposal in
> one session.
> I have even more doubts about that through e-mail.

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".  It will definitely not be consensus or
even majority but usually something I'm personally satisfied with.  So,
I do what I can to generate "traffic".

Quote:
> ... But how do
> you measure in e-mail whether someone just made a whimsical remark
> or has a very fierce position about something?

I assume that if someone took the time to say something, then it is
important and serious and worth listening to.  (Unless it is :-)

Quote:
> I am willing to try such an e-mail discussion if I could be
> convinced that it is possible. We wouldn't be forced to compress that in
> one or two weeks before APL94; a well supported proposal in APL95 is
> nice enough in my view. Maybe initiated in an APL94 session.
> But is this feasable?

I am willing to contribute to such a discussion regardless of outcome,
but one does not a discussion make.  Eke, if you drop out then this thread
is dead.  I look at it both as an "intellectual challenge"--does such an old
problem admit a new, elegant solution once the combined wisdom of c.l.a. is
put to work--and for pragmatic reasons, of course.  (In fact the pragmatic
constraints are what makes the problem interesting.)

Let us not try to make a consensus, but to clarify the problem, and as I said
to formulate a small number of clearly stated positions.  Does everyone
understand the problem?  (I don't.)




Sun, 16 Feb 1997 06:35:26 GMT  
 Proposal for control structures in APL

|> It might be encouraging to consider what the linux community has
|> accomplished through the net.  Those unaware of the linux effort might

The big difference there is that they were all code developers, hence
could make meaningful decisions and implement them. We have very
little influence on what IBM or Manugistics does.

To do the same as linix here we'd clearly have to make a pd apl. Is
APL 11 good enough? We'd also need lots of time to work on this stuff,
which I haven't had for quite a while...

--
Sam Sirlin



Sun, 16 Feb 1997 08:49:18 GMT  
 Proposal for control structures in APL

Quote:


>|> It might be encouraging to consider what the linux community has
>|> accomplished through the net.  Those unaware of the linux effort might

>The big difference there is that they were all code developers, hence
>could make meaningful decisions and implement them. We have very
>little influence on what IBM or Manugistics does.

>To do the same as linix here we'd clearly have to make a pd apl. Is
>APL 11 good enough? We'd also need lots of time to work on this stuff,
>which I haven't had for quite a while...

I think the best way to deal with standardization [whether through
PD APL or some other way] of control structures is:

a. NOT to attempt to do design by committee, which is what I see
   happening in c.l.a.

b. To promote a meeting of language designers and developers who
   can sit down in a room with a blackboard and hash out their
   respective positions and opinions, and hopefully come to a
   uniform position and design.

   I have been promoting control structures at recent Minnowbrook
APL Workshops, and suggest that this type of meeting is a much better
forum than c.l.a. Like many threads in the net, these things often
boil down to esthetics and personal taste, and there IS not right
answer, but nobody who's posting seems to realize that.

Bob



Sun, 16 Feb 1997 22:41:08 GMT  
 Proposal for control structures in APL

Quote:

>>To do the same as linix here we'd clearly have to make a pd apl. Is
>>APL 11 good enough? We'd also need lots of time to work on this stuff,
>>which I haven't had for quite a while...

Which is a problem we all have.  How can we "discover" students who
are willing and able to put in some hacks?  Can one of the academicians
here get an APL student?  Anyway, I think APL\11 is a good place to start.

Quote:
>I think the best way to deal with standardization [whether through
>PD APL or some other way] of control structures is:

>a. NOT to attempt to do design by committee, which is what I see
>   happening in c.l.a.

Actually I don't see much design work going on in c.l.a., certainly
not by committee.  Lots of (useful) opinions, but no detailed design.
Perhaps folks can submit competing proposals by the end of the week or
something :-)  Just a clear and concise proposal, with arguments to come
later.

Quote:
>b. To promote a meeting of language designers and developers who
>   can sit down in a room with a blackboard and hash out their
>   respective positions and opinions, and hopefully come to a
>   uniform position and design.

This would be best of course, but it hasn't worked.  So I think we
should try something new, i.e. do it on the Internet.

Quote:
>   I have been promoting control structures at recent Minnowbrook
>APL Workshops, and suggest that this type of meeting is a much better
>forum than c.l.a. Like many threads in the net, these things often
>boil down to esthetics and personal taste, and there IS not right
>answer, but nobody who's posting seems to realize that.

Well, I try to outline different possibilities and ask people to voice
their preferences.  Show of hands please, EXPRESSION-LEVEL CONTROL or
STATEMENT-LEVEL CONTROL?  I have discussed this basic question in detail;
is there anyone who really favors controlled expressions?  Why?

Bob, is Minnowbrook "open", and can it be done "on the cheap"?




Mon, 17 Feb 1997 00:01:14 GMT  
 Proposal for control structures in APL
William Chang:
.  Show of hands please, EXPRESSION-LEVEL CONTROL or STATEMENT-LEVEL
.  CONTROL?  I have discussed this basic question in detail; is there
.  anyone who really favors controlled expressions?  Why?

What's the difference between an expression and a statement?  Near as
I can tell, statements are "expressions that don't take any arguments,
and maybe have no result".  

More on this later, once I get some time to sit down and write a
serious post.

--
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 00:42:17 GMT  
 Proposal for control structures in APL

Quote:



>>>To do the same as linix here we'd clearly have to make a pd apl. Is
>>>APL 11 good enough? We'd also need lots of time to work on this stuff,
>>>which I haven't had for quite a while...

>Which is a problem we all have.  How can we "discover" students who
>are willing and able to put in some hacks?  Can one of the academicians
>here get an APL student?  Anyway, I think APL\11 is a good place to start.

My own opinion [which you KNOW I'm so reluctant to share, but will
anyway...   8^} ] is that APL is DEAD as far as getting academia interested
in it. The character set, lack of control structures, lack of OO
{today's fad}, lack of an EFFECTIVE Standard (by which I mean you
have a hope in hell of picking up an application and moving it to other
vendors' systems, EVEN if it adheres to the letter of the ISO Standard),
and so on, simply means that academics aren't going to look at it.

Languages such as J DO offer an alternative, in that they have not been
tarred with APL brush.

Re PDAPL's otherwise: This was tried before, with the creature from IAPL.
It didn't work for several reasons, of which extremely limited design
and an attempt to make it proprietary in spite of being "pd", were
prime.

Don't waste your/their time.

Quote:
>Actually I don't see much design work going on in c.l.a., certainly
>not by committee.  Lots of (useful) opinions, but no detailed design.

Exactly my point. The place where design takes place is when you
STOP handwaving about Sherwood, and get down to hammering out
detailed design.

Quote:

>Bob, is Minnowbrook "open", and can it be done "on the cheap"?

a. Minnowbrook APL Workshops are by invitation only. If Garth Foster,
   who is the Inviter, gets word that X is a good person to invite,
   X will almost certainly get an invite.

b. On the cheap: Not really that expensive, compared to something like
   a Conference Across the Sea.
   Most of the money goes to pay for room& board, so it's hard to
   see where it could be a lot cheaper.

Bob



Mon, 17 Feb 1997 03:59:00 GMT  
 Proposal for control structures in APL

Quote:



>Well, I try to outline different possibilities and ask people to voice
>their preferences.  Show of hands please, EXPRESSION-LEVEL CONTROL or
>STATEMENT-LEVEL CONTROL?  I have discussed this basic question in detail;
>is there anyone who really favors controlled expressions?  Why?

Statement-level control traditionally FORCES use of variables to
carry information, which is at odds with some schools of functional
programming.

Expression-level programming avoids this, but MAY be harder to
read if the design is done wrong. Note that expression-level
programming NEED NOT imply:
    - doubled quotes, ala execute
    - hairy parentheses

In particular, I think that block structure and statement level
operation may be usable without the need for variales.
As an example, look at SISAL, in which control structures
are functional, returning the result of the entire loop's execution.

This is similar to the iterator in an early version of J.

Bob



Mon, 17 Feb 1997 04:08:23 GMT  
 Proposal for control structures in APL

Quote:
>William Chang:
>.  Show of hands please, EXPRESSION-LEVEL CONTROL or STATEMENT-LEVEL
>.  CONTROL?  I have discussed this basic question in detail; is there
>.  anyone who really favors controlled expressions?  Why?

>What's the difference between an expression and a statement?  Near as
>I can tell, statements are "expressions that don't take any arguments,
>and maybe have no result".  

I think my earlier reply to Eke on APL-L must have not reached c.l.a.  It may
be harder to design and implement controlled expressions than statements.



Subject:      Re: Control structures in APL
Date:         Wed, 24 Aug 1994 13:58:01 -0500


Quote:
>Stimulated by the control-structure discussion, last days emphasis
>shifted towards "do we read APL lines from left to right or vice
>versa?" and "do we read programs from first to last line or v.v.?".

Eke writes how he, and he guesses others, read APL.  I'd prefer not to get
in too deep yet, other than to say I tend to browse (memorize) chunks of
code and then conceptualize in my head, before actually digging in.  
(But I am certainly not very experienced at reading other people's APL.)
In my view, there's no longer very good reason to write long lines with
internal assignments, when <> is available.  Short lines with <- are fine
because they are easily read left to right.  I _prefer_ not to scan (parse)
right to left.

Quote:
>[3]...[2]...[1]...         [3]...[2]...[1]...
><----------------          ----------------->
>parsing view               conceptual view

 [top to bottom]            [bottom to top???]

The words I would use are "imperative" and "functional" (or "applicative").
I disagree that the latter is best read bottom to top, because the functional
view doesn't really work across lines, especially in the presence of branches
and loops.

Quote:
>Coming back to control structures. As I read APL mostly in the parsing
>view and also prefer to see the controlling expression before I see the
>controlled expression, I propose to set the controlling part at the
>right in the first line  of the controlled  block.

Again, it bothers me a great deal that the form of a block has to be changed
just because a "newline" is inserted in the middle.  It would be a pain to
have to move the control around.  I tend to agree with Raul on this, that
to be consistent the control (of an expression) has to be at the end,
bottom right, and a multi-line expression has to be evaluated "backwards".
Placing the control at the right of the first line seems overly concerned
with line structure rather than block structure.  

My view is that backwards evaluation only applies to expressions with control,
not statements.  A "controlled expression" can be written

  {{expression-block1} {expression-block2}...{expression-blockN}} [control]

with arbitrary line breaks.  It is simply a notation for indexing a strand
using lazy evaluation.  There should be no loop form.  On the other hand,
a "controlled statement" might look like

  (control) {statement-block1} {statement-block2}...{statement-blockN}

with line breaks anywhere except after a closing }.  A loop form should
be explicitly provided.  The case form also needs work.

I'm not sure whether one or the other or both should be provided.  I think
much of the debate here actually hinges on this distinction between controlled
expression and controlled statement.  I also think the control clearly has
to be at one end or the other, top left or bottom right.

Quote:
>Raul and Bill wonder about the future of labels in a phantasy land
>where APL had good control structures implemented. My favourite answer
>would be to declare -> and label: outlawed. I have programmed hundreds
>of programs, big and small, in other languages and never needed GOTO.
>Rauls proposal is more sensible of course: keep it for compatibility with
>old programs.

I'm curious whether you have ever used continue, break, exit, or return.
These are of course all gotos.  If you outlaw -> you will have to provide
these somehow.  Also regarding Jack Rudd's comment, I think we are all
working under the assumption of backward compatibility.

Quote:
>Reality is even more different though. Not only did Manugistics introduces
>word-like control structures (I appreciate this move although not the
>implementation). But recently they proposed to add the keyword GOTO
>too.
>How low can you go. Did they never heard about structured programming?
>This is really IN(C)A: Its NOT APL (sorry folks, but I hate it if APL
>is going this way).

I think, they found out that gotos are actually needed.  While there are
(imperative) languages without any kind of break, return (->0 in APL), or
exit (-> no right argument), I _personally_ would not waste my time with one.

Quote:
>Bill raises the question "what is the definition of a controlstructure?"
>I loosely use it for that piece of code that contains a controlling
>part (including the keywords IF/THEN or keysymbol -> { } or whatever)
>and a controlled part. The latter can be a control structure again,
>but not the former, I assume.

Ah, here the distinction between controlled expression and controlled
statement is crucial.  If you allow the former then the "controller" can
certainly be another controlled expression.  If you allow only the latter
then nested control can only appear in the controlled part, not in the
controller expression.  Which do people prefer?




Mon, 17 Feb 1997 06:04:59 GMT  
 Proposal for control structures in APL

Quote:
>My own opinion [which you KNOW I'm so reluctant to share, but will
>anyway...   8^} ] is that APL is DEAD as far as getting academia interested
>in it.

I meant, can an APLer professor find some funds for a student?

Quote:
>Languages such as J DO offer an alternative, in that they have not been
>tarred with APL brush.

>Re PDAPL's otherwise: This was tried before, with the creature from IAPL.
>It didn't work for several reasons, of which extremely limited design
>and an attempt to make it proprietary in spite of being "pd", were
>prime.

Perhaps it can be tried again, without those fateful decisions.  There
is a sore need (I think) of a free or inexpensive Unix APL.  Right now
APL\11 is the only one that doesn't cost several THOUSAND dollars (it's free).
It can talk to Unix, has a session manager called fep, uses vi, and
understands ASCII (APL!).

Quote:
>>Actually I don't see much design work going on in c.l.a., certainly
>>not by committee.  Lots of (useful) opinions, but no detailed design.

>Exactly my point. The place where design takes place is when you
>STOP handwaving about Sherwood, and get down to hammering out
>detailed design.

I have posted bits of several designs.  I'd be very interested to see yours!




Tue, 18 Feb 1997 01:11:36 GMT  
 Proposal for control structures in APL

Quote:
>My own opinion [which you KNOW I'm so reluctant to share, but will
>anyway...   8^} ] is that APL is DEAD as far as getting academia interested
>in it. The character set, lack of control structures, lack of OO
>{today's fad}, lack of an EFFECTIVE Standard (by which I mean you
>have a hope in hell of picking up an application and moving it to other
>vendors' systems, EVEN if it adheres to the letter of the ISO Standard),
>and so on, simply means that academics aren't going to look at it.
>Languages such as J DO offer an alternative, in that they have not been
>tarred with APL brush.

The character set:
Do you really LIKE the J character set? J code looks as if somebody has
played tennis with the keyboard. J code is a complete MESS.
The other things:
Who will care for OO in some years from now? Have you ever written programs
in an OO language? OO is DEAD, not APL.
Who cares for control structures? I SWEAR that I will not even take a
look at APL*PLUSIII+n as long as they keep on including all this windows-
stuff, do-while loops, and OO-mickey-mouse-features, but neither complex
arithmetic nor adjustable numerical precision. We do not need no control
structures, we have "conditional branch". Where are the control
structures in J? Do you believe "`" or "^:" are control structures? I don't.
I believe this is a complete MESS. Standard? Yes there is a standard APL-
system. It is called IBM-APL2. The only true APL2 and the best is: It does
not run under windows. One last comment on J: It is a complete MESS.
Just my opinion,
Bernhard Strohmeier


Tue, 18 Feb 1997 08:09:48 GMT  
 Proposal for control structures in APL

Quote:

>The character set:
>Do you really LIKE the J character set? J code looks as if somebody has
>played tennis with the keyboard. J code is a complete MESS.

Yes, I DO like the J character set. I'm using it now. SO are you.
It's called ASCII. Millions of netters around the world use it every
day without problems. I can use the text editor of my choice, and I
don't have to install fonts, coding schemes, keycap stickers, etc.

You, however, appear to have a problem with the J spelling scheme, however.
Don't feel bad. You're in good company with all those C programmers
who say "APL is a write-only language because it has all these funny
symbols". As  I said before, you can define your own spelling in J,
so don't feel confined by the shorthand which J provides as a default.

Quote:
>The other things:
>Who will care for OO in some years from now? Have you ever written programs
>in an OO language? OO is DEAD, not APL.

This same theme was sung for control structures. APLers are finally realizing
that there is SOME virtue in them. Ditto OO: Not the solution for
everything, as some claim, but there are sound ideas in OO, and we
ignore them at our peril. If you ever passed an argument to a function,
and spent time chasing far far down the stack, only to find that a
strand had turned your character array into a nested array and none of
the functions along the way objected, then perhaps you, too, could
benefit from OO in APL.

Quote:
>Who cares for control structures? I SWEAR that I will not even take a

{remainder of diatribe deleted}

This is a rerun, I believe.

Quote:
>I believe this is a complete MESS. Standard? Yes there is a standard APL-
>system. It is called IBM-APL2. The only true APL2 and the best is: It does
>not run under windows. One last comment on J: It is a complete MESS.

Sigh. Let's try this again. "Standard": This means, in the APL biz,
"Conforming to the ISO Standard for the Programming Language APL".
There are MANY such APL systems.


Sun, 23 Feb 1997 06:41:31 GMT  
 Proposal for control structures in APL

Quote:

>>Yes, I DO like the J character set. I'm using it now. SO are you.
>>It's called ASCII. Millions of netters around the world use it every
>>day without problems. I can use the text editor of my choice, and I
>>don't have to install fonts, coding schemes, keycap stickers, etc.

>Congratulations. You are right. Now we know what the critical point in
>programming is: To choose an editor. Obviously.

Yes.  Believe it or not, this sort of preference drives a lot more
decision-making on language choice than does Fancy_Primitive_Number_72.

If you don't believe it, go get a job trying to peddle APL in the real world,
before you dismiss it out of hand.

Quote:
>({*filter*}deleted)

   Thanks.

Quote:
>>Sigh. Let's try this again. "Standard": This means, in the APL biz,
>>"Conforming to the ISO Standard for the Programming Language APL".

>I see. At first you say there is no standard for APL, and then you say
>you meant the available APL-systems are not consistent with some obscure ISO
>standard. There is difference. Say what you mean.

You is not reading what I is writing. There IS an ISO Standard for APL.
I happen to be one of many people who worked on it. It happens to be
a political document which has little relevance to bringing APL vendors
together to provide products which allow programmers to write portable
applications. It's better than nothing, but APL code is a hell of a lot
harder to port than C.

If you find the Standard to be obscure, perhaps you have not read it?
Go read ISO N8485. It's available from your National Standards Bureau.

Quote:
>By the way: How many people around the world use J? 100? It does not
>make sense to waste the most valuable ressource in the world - my time -

                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

My. Modest, aren't we?

Quote:
>for a language nobody besides some enthusiast gives a damn for.

As I pointed out previously, NO computer language on the planet has
developed a following in less than 10 years. J has been around for
less than 4 years. Please ask me this question again in 6.5 years.

I'll bet there will be more J users than APL users at that time, and ONLY
because J isn't hobbled with an oddball character set.

Bob



Mon, 24 Feb 1997 10:21:46 GMT  
 Proposal for control structures in APL

Quote:
>As I pointed out previously, NO computer language on the planet has
>developed a following in less than 10 years. J has been around for
>less than 4 years. Please ask me this question again in 6.5 years.
>I'll bet there will be more J users than APL users at that time, and ONLY
>because J isn't hobbled with an oddball character set.               ^^^^

Hmm. Weren't there keyword variants of APL available some decade ago?
(obviating the need for special charactes). If so, how come they
haven't caught on and become more widespread, if the prime crux is the
character set?

I suspect there is more to it than a character set. Concerning J, my
personal view is: "exceptionally elegant from a functional/semantic
point of view; but horrendously ugly program code from an aesthetic
point of view". Aren't you overestimating the character set obstacle,
and underestimating the value of first impression of its look, and
"sex appeal"?

Some people say I can define my own spelling. However, since it's
not part of any fixed definition, people around the world will most
propably adhere to the "core" stuff (unless someone standardizes the
words). Moreover, from what I have seen, the way J is defined, it seems
to discourage lines that become long (because of verbose definitions).
In lisp, on the other hand, making line feeds often does not abscure
the understanding of the code - on the contrary - it improves it. It
would be nice if the same thing was true for J. But since J and APL
evaluates right to left, I doubt line feeds would make nice code (since
I doubt reading bottom-up will be acceptable to the bulk of the
computing community).  What's your opinion? Can J statements be nicely
multiline formatted (i.e such that it improves rather than obscures
understandability, in case I chose wordy definitions of J primitives)?
Are there any experiments along this route?

/HB



Tue, 25 Feb 1997 00:35:28 GMT  
 
 [ 31 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Proposal for control structures in APL

2. Proposal for control structures in APL (SAMSON)

3. Control structures; discussion or proposal

4. Control Structures in APL

5. Control Structures in APL

6. Control structures in APL

7. APL Control Structures

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