APL slash bang (Repost) 
Author Message
 APL slash bang (Repost)

-----------Message forwarded from IPSA Mailbox-------------

no. 6105624 filed 20.06.46  mon 30 mar 1992
from dgil
to   uclapl
subj Re: APL slash bang (Repost)
ref  6103043

     Bill Chang misunderstands my objections to some of Dan LaLiberte's

1.  I agree with Bill that there are alternatives to no precedence.  The
    languages that I have seen with a rich primitive set have wound up with a
    complicated (dare I say 'unmanagably complicated'?) precedence scheme, and
    I think that has proved to be a mistake.  Bill suggests a simple scheme,
    and I agree that its simplicity and seductive similarity to the scheme we
    learned in elementary school are appealing.
         BUT:  Dan suggested something that he implied was a *partial*
    precedence scheme.  I don't think that's the same thing as Bill's simple
    example, in which every primitive clearly has an assigned precedence.
    (Perhaps this is what Dan meant, in which case I can only plead that I was
    misled by his imprecise terminology.)

2.  My impression is that right-to-left evaluation of Functional programs
    (assuming the conventional placement of arguments; i.e. without radically
    disrupting additional aspects of syntax) minimizes the necessity for
    syntactic devices for deviations from that evaluation order.  It is my
    understanding that this accounts for some noticable portion of the use of
    parentheses in LISP.
         As I understand Bill's comment, Nial introduces instead the '.' syntax
    to mark deviations from the normal evaluation order.  In the midst of other
    discussion about the counter-intuitiveness of J's use of braces and
    brackets, I must note that I find the use of parentheses to re-order
    evaluation to be most intuitive, and am not sure I see the relevance of
    Nial as an alternative example.

     The combination of uniform/no precedence and right-to-left evaluation
produces a starkly simple syntax, easy both to implement and to use.  Dan's
suggestions would complicate both implementation and use, in ways that (I
inferred) he seemed unaware of, presumably for the sake of lowering the
learning curve.

     To me, these specific suggestions of Dan's conveyed a strong impression
that his criticisms of the language proceeded from a position of "It's not
what I'm used to", rather than from an understanding of the cost/benefit
tradeoffs and issues of language design.  I'm aware that designers of other
languages -- including some that I use quite regularly -- made other choices,
but it's not obvious to me that those alternatives have produced *better

                                       Dave Gillett

This posting is forwarded from an internal Reuters mailbox.
No statement or opinion contained herein should be taken as
being Reuters policy, or even as being approved by Reuters,
in any way.

Sat, 17 Sep 1994 05:00:06 GMT  
 [ 1 post ] 

 Relevant Pages 

1. APL slash bang (Repost)

2. APL/! (APL slash bang)

3. APL slash bang

4. APL! (APL bang)

5. APL! ("APL bang") and examples (REPOST)

6. To bang or not to bang

7. APL Newsreader & c.l.a Archive [REPOST]

8. APL Newsreader & c.l.a Archive [REPOST]

9. APL Newsreader [REPOST]

10. APL character set (Sun xterm solution) REPOST

11. APL Newsreader [REPOST]

12. APL Newsreader [REPOST]


Powered by phpBB® Forum Software