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

Bill Chang:
: I still think this discussion should take place on c.l.a./apl-l.

: it gets archived and may reach a lot of interested people who
: cannot/did not post.

Intro: What Chang is refering to is an email annex to the discussion
on control structures.  I'm keeping a mail file of the discussion: at
this point the thread occupies about 80K -- and about 25K of that is
the initial message by David Gurr (which responds to a number of
points raised in the posted thread).

Gurr started up the email conversation because he didn't want to get
flamed for posting news articles that were "too long".  However, I
agree with Chang: this thread has some substantial information in it,
and probably should have been posted to the newsgroup.

Unless I receive objections, I'm going to post these "previously
unposted" messages to the newsgroup "as if they had been posted by
their original author".  That should make it look as if the entire
thread (except for the bit that goes to apl-l directly) had been
posted by a standard news posting mechanism.  If I receive positive
comments [and no negative comments], I'll make this posting in about
24 hours.  Otherwise, I'll wait till Saturday the 17th to make the
postings.

All bets are off if I receive negative comments.

--
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 Mar 1997 01:41:11 GMT  
 Proposal for control structures in APL
David Gurr communicates by email:

Quote:
> Back to the purported subject of the thread:  control structures.  The single
> most important control in any functional language is recursion.  For simple
> recursion (ie tail recursion), recursion should be implementationally
> equvelent to iteration.  It should not increase the stack depth, etc.  But
> inorder for this to work, one must have lexical scope.  This is perhapse
> the most important m{*filter*}of the developement of Lisp (and evolution of Scheme).
> The second point concerning control structures is that IMHO the philosopy of
> elegance and generality forces us to include call-with-current-continuation
> in APL.  call/cc and dynamic scope is hard, call/cc with pseudo dynamic
> scope is truely scary.

> If you ask my opinion, there are two must haves for APL control for the future:
> tail-recursion and call/cc.  If you want to make this change in small steps,
> OK.

Please translate/expand this so APLers can understand, and post or publish it!

I think we all agree (since the beginning of this thread?) that APL needs
nested blocks and lexically scoped local functions.  I think these can be
added to existing interpreters, and proposed an APLish (if old-fashioned)
syntax.  APL also needs "safe" first class functions; it is not entirely clear
to me that these can added easily, but I'm sure they can be added _somehow_.
As I mentioned, OO can be implemented very simply using closures.


used to create a first class closure out of a block or (possibly higher-order)
subroutine/subfunction, but I really think there are some subtleties to be
worked out...  For example, current syntax for funargs (of operators) is
simple but limited and not really satisfactory.  We need a (nice) notation for
manipulating and returning (upward) funargs.  One possibility is to return
the funarg label; it acts like a number (as in current APL) inside its
definition environment but becomes a closure when it is passed out; a "gosub"
(args)->f will invoke it (the usual notation, for up to two parameters, seems
to conflict with strand notation, but maybe this can be worked out).
Is it necessary to be able to assign funargs to/inside variables explicitly?
Would passing funargs as parameters or through scoping be enough for most
or all purposes?  As I said before, function assignment can become very
unstructured.  I must also confess that I have not liked any of the old
(APL literature) notations for funarg parameters (especially), locals, and
invocation; they seem _foreign_.  (I do like the idea of tacit/phrasal forms.)

Re: "strict" local variables
I agree that this band-aid alone won't do it.  However it might be useful
for local block variables (as I proposed), which would remove environment
overhead on block entry/exit.  Notation-wise, I think strict locals should
be declared inside blocks { local1; local2; code } with optional line-breaks
(and comments) after the ;'s.  This is where they belong, not in the function
header; the point is nobody outside the block should know they exist.

Re: LISP vs scheme in _The Structure and Interpretation of Computer Programs_
I don't think this book discusses the differences and the history enough.
A few pages cover dynamic scoping, its rationale and implementation.  It seems
one really has to go back to the original '70s MIT AI Memos (now folklore of
course) where the case for static scoping was made.  Script-based scheme (so
lexical is static not dynamic) was relatively new and very much changing when
this book was written (published in '85 but the notes had been in use).




Sun, 02 Mar 1997 01:46:21 GMT  
 Proposal for control structures in APL
I'm somewhat reluctant to have my email posted. In particular, I may
have said things in email which I would NOT post, for various reasons...

Might I suggest that a more sensible approach would be to attempt to
extract a summary of what has been said here, and post THAT instead?

This would also serve to boil down all the messages into a [hopefully]
coherent whole.

Bob



Sun, 02 Mar 1997 03:26:10 GMT  
 Proposal for control structures in APL

Quote:

> I'm somewhat reluctant to have my email posted. In particular, I may
> have said things in email which I would NOT post, for various reasons...

I don't remember seeing anything _that_ controversial.

Anyway this is why I prefer cla to email--one objection and stuff goes
out to bit haven.  Note that I have refrained from joining this email
discussion as much as I can.

Quote:
> Might I suggest that a more sensible approach would be to attempt to
> extract a summary of what has been said here, and post THAT instead?

Who's going waste precious time to do that?  It's hard enough keeping up
with the new mail.  And more email means a larger backlog to deal with.

Quote:
> This would also serve to boil down all the messages into a [hopefully]
> coherent whole.

That would be useful, and can be done in addition to posting the thread.
If people want, they can condense their own emails (minimize quotes) and
send them to Raul (is that okay with you?).

Quote:
> Bob




Sun, 02 Mar 1997 10:48:53 GMT  
 Proposal for control structures in APL
David Gurr replies to my letter:

Quote:
> > APL's dynamic scoping is actually lexical scoping.
> How so?

Variables _are_ resolved in their lexical context--only there isn't much of
one without nested blocks.  It is not "static" scoping, which would mean free
variables are bound to (static) globals.

Quote:
> > Re: Fluid (dynamically scoped) variables necessary for a FEW applications
> > To pretty-print or to draw a window, for example.
> > This need can be removed if one could build "objects" using closures.

> I dont think that objects can take the place of dynamic scope, or that
> they should.  The "dynamic scope is evil" line is RB's.  I favor DS for
> the same applications it is used for in Lisp and Scheme.

Perhaps you can elaborate.

Quote:
> > Lexically scoped local functions is a big step toward that goal.

> I know that a fair number of Schemer's favor closured based OO.  I
> am not one of them.  To make a long story short, I like CLOS's MOP,
> I like Axiom, I dont think that the semantics of OOP are know, and
> all current designs are buggy.

I agree that OOP is far from settled, however we should pat ourselves
on the back if we get as much as closure-based OO out of this.  There's
also a little bit of salesmanship here: WE NEED CLOSURES FOR OO.
Please don't spoil it for us :-)

Regarding your earlier note that CLOS can handle dynamic type/schema
redefinitions, perhaps you can explain how it's done and how it might
be relevant to APL, since it's obviously something everyone's interested
in.  I use neither Common LISP nor CLOS (Common LISP Object System).
I assume it would take several large steps to get that far.  Yes or no?
Also, CLOS sounds very different from the strongly typed systems Jay and
Bob advocate (i.e. OO vs FP).




Sun, 02 Mar 1997 11:22:44 GMT  
 Proposal for control structures in APL
Bob Bernecky:
. > This would also serve to boil down all the messages into a [hopefully]
. > coherent whole.

Bill Chang:
. That would be useful, and can be done in addition to posting the
. thread.  If people want, they can condense their own emails
. (minimize quotes) and send them to Raul (is that okay with you?).

Sounds good, here's my current plan:

I wait a bit more for comments
Anyone who wants to send me editted versions of their stuff can do so
I post the thread (with distinctive headers), quickly editing out
  anything Bob said that's controversial, and anything that I notice
  that appears content free.

Ideally, I'd like to spend no more than a half an hour on this.

Oh, one other thing, I didn't save any copies of my own mailings.  If
I wrote anything that should be posted, could someone forward a copy
to me?

Later,

--
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 Mar 1997 13:35:38 GMT  
 Proposal for control structures in APL
(for c.l.a readers that find this a bizare topic to find on
an apl newsgroup, please flame me (David Gurr) and Bill Chang.
I'm posting at Bill's wishes.  If you reply to this message

list of addresses.  -David )

Bill Chang:

Quote:
> David Gurr communicates by email:
> > ...blah blah blah...APL must have tail-recursion and call/cc.
> > ... blah blah ...
> Please translate/expand this so APLers can understand,

Ouch!  John can you help me out on this one?  I'm not much of an
educator.  Tail recursion is exactly thoes recursions that are
exactly equvelent to simple iterations.  Continuations are functions
that represent "what the rest of the program computes" and are
functional counterparts to gotos and escapes.  Both are required
reading for computer langage designers but I dont know of a good
intro.

Quote:
> and post or publish it!

> I think we all agree (since the beginning of this thread?) that APL needs
> nested blocks and lexically scoped local functions.

Do all agree? I do.

Quote:
> I think these can be
> added to existing interpreters, and proposed an APLish (if old-fashioned)
> syntax.

I wont argue over syntax.

Quote:
> APL also needs "safe" first class functions; it is not entirely clear
> to me that these can added easily, but I'm sure they can be added _somehow_.

Anyone want to comment on why first class functions might not be safe?
They are safe in other languages.  Equality of functions is usually
a bit weird, but otherwise.

Quote:
> As I mentioned, OO can be implemented very simply using closures.

But might be better implemented other ways.

Quote:

> used to create a first class closure out of a block or (possibly higher-order)
> subroutine/subfunction, but I really think there are some subtleties to be
> worked out...

I'm very stongly in favor of first class functions, so I will not be
enthusiastic about proposals that do not include them completely.
Other's priorites are different.

Quote:
> For example, current syntax for funargs (of operators) is
> simple but limited and not really satisfactory.

The f & g convention?  I agree.

Quote:
> We need a (nice) notation for
> manipulating and returning (upward) funargs.

lambda notation extended by array matching.   One way to do this is to
make lambda an operator over expressions (expressions are NOT first class),
"(A lambda B)(A + B)" whould be equv. to "+"; (lambda (A B C))(A + B + C)
would create a function that takes enclose(iota(3)) to 3.

Quote:
> One possibility is to return
> the funarg label; it acts like a number (as in current APL) inside its
> definition environment but becomes a closure when it is passed out;

I think that it should become a continuation rather than a closure.

Quote:
> a "gosub" (args)->f will invoke it

The usual understanding of -> is goto, not gosub.  goto invokes continuations
rather than closures.  To be a conforming extension, we must continue to allow
-> to invoke continuations, but if -> can invoke both, the compiler cannot
assume that X in the context "->X" is invoking a continuation and thus would
be prevented from making some optimizations.  On the other hand, Scheme does
allow both continuations and closures to be invoked by the same mechanism.

Quote:
> (the usual notation, for up to two parameters, seems
> to conflict with strand notation,

If the strand object is shape 0, then niladic invocation of f, if shape 1, then
monadic, if shape 2, then dyadic.  Scheme's version of -> is called apply.
It is needed match collections of arguments with functions that take more than
one arguement.  (I think apply is largely a syntax bug in Scheme, but few
others agree.)

Quote:
> but maybe this can be worked out).
> Is it necessary to be able to assign funargs to/inside variables explicitly?
> Would passing funargs as parameters or through scoping be enough for most
> or all purposes?
> As I said before, function assignment can become very  unstructured.

ANY assignment can become very  unstructured.

Quote:
> I must also confess that I have not liked any of the old
> (APL literature) notations for funarg parameters (especially), locals, and
> invocation; they seem _foreign_.  (I do like the idea of tacit/phrasal forms.)

> Re: "strict" local variables
> I agree that this band-aid alone won't do it.  However it might be useful
> for local block variables (as I proposed), which would remove environment
> overhead on block entry/exit.  Notation-wise, I think strict locals should
> be declared inside blocks { local1; local2; code } with optional line-breaks
> (and comments) after the ;'s.  This is where they belong, not in the function
> header; the point is nobody outside the block should know they exist.

> Re: LISP vs scheme in _The Structure and Interpretation of Computer Programs_
> I don't think this book discusses the differences and the history enough.
> A few pages cover dynamic scoping, its rationale and implementation.  It seems
> one really has to go back to the original '70s MIT AI Memos (now folklore of
> course) where the case for static scoping was made.

About the only people who have easy access to these papers are people at places
like MIT and Stanford so I did not reference them.  But they are definitly
the historical documentation of the developement of the ideas.

Quote:
> Script-based scheme (so
> lexical is static not dynamic) was relatively new and very much changing when
> this book was written (published in '85 but the notes had been in use).



-David


Mon, 03 Mar 1997 06:40:43 GMT  
 Proposal for control structures in APL
I'm not going to tackle describing tail recursion or continutations,
except to point out that Donald McIntyre has been doing tail recursion
for years [in his "Direct Definition" code].  I expect that many
APLers would find McIntyre's writing very approachable.

David Gurr:
: lambda notation extended by array matching.  One way to do this is
: to make lambda an operator over expressions (expressions are NOT
: first class), "(A lambda B)(A + B)" whould be equv. to "+"; (lambda
: (A B C))(A + B + C) would create a function that takes
: enclose(iota(3)) to 3.

Doesn't K do something like
{[dummyvars] expr}
?

So, for example, a lambda expression with three variables may be
expressed something like
{[a;b;c] a+b*c}

As I understand it, currying is automatic, so you can do something
like
1 {[a;b;c] a+b*c}[3] 2

I'm not sure how K deals with ambivalence, however.

--
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 Mar 1997 11:04:23 GMT  
 Proposal for control structures in APL
   Bill Chang writes:
Quote:
>David Gurr replies to my letter:

>> > APL's dynamic scoping is actually lexical scoping.
>> How so?

>Variables _are_ resolved in their lexical context--only there isn't much of
>one without nested blocks.  It is not "static" scoping, which would mean free
>variables are bound to (static) globals.

Because, local variables override the values of free variables in called
functions, APL is dynamically scoped; not lexically scoped.  Lexical scoping
could be simulated in APL's dynamically scoped environment by giving lexical
variables a qualified name that includes the names of the enclosing functions.

This approach has a few problems:

 - It doesn't support closures
 - It's may be possible to create a case where it's not identical to true
   lexical variables; I don't think this would occur in practice.

It would be easier to add to existing interpreters then true lexical variables.

Kim



Mon, 03 Mar 1997 08:48:36 GMT  
 
 [ 9 post ] 

 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