Newsgroups: comp.lang.apl
Path: watmath!watserv1!utgpu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!jvnc.net!phage!wchang
From: wchang@cshl.org (Bill Chang)
Subject: Re: Expressiveness of Language
Message-ID: <1992Mar23.200055.737@cshl.org>
Summary: Essential APL?
Sender: news@cshl.org (NO MAIL)
Organization: Cold Spring Harbor Laboratory
References: <ROCKWELL.92Mar20072450@socrates.umd.edu> <1992Mar20.184205.4943@watmath.waterloo.edu> <LIBERTE.92Mar20173238@birch.cs.uiuc.edu>
Date: Mon, 23 Mar 92 20:00:55 GMT
Lines: 96

In article <LIBERTE.92Mar20173238@birch.cs.uiuc.edu> liberte@cs.uiuc.edu 
(Daniel LaLiberte) writes:
>... Now, as long as we are stuck with linear ascii text, we have to make
>the best of it.  We have very few barely meaningful operator-like
>characters to work with, so I think it better to use them sparsely 
>rather than jumbled together to confuse the eye.
>
>... Much more important is that it be uniform and
>statically parsible without complex context sensitivity so that one
>can get into the flow of an expression without stumbling on the
>notation.
>
>As a general guideline, I think C and Icon make good use of most
>operator characters... 
>
>Dan LaLiberte
>liberte@cs.uiuc.edu
>(Join the League for Programming Freedom: league@prep.ai.mit.edu)

Perhaps a compromise between our positions is possible?  That is,
decide on a small set of simple and critical operators and give them 
the best looking ASCII symbols, and use keywords/abbreviations/initials/
whatever for the rest.  In fact that is what I tried to do with APL/!.

The problem is that there are many important APL operators that do 
not have obvious ASCII equivalents.  They are so basic and so ubiquitous 
that having to write "take" or "drop" or "rho" or "iota" all the time 
just won't do!  I hope you would agree that they deserve special symbols.
(In APL/! they are | ~| / ! respectively.)

It is arguable whether higher-order functions such as reduce; scan;
inner product; outer product; and each should be treated as simple
concepts and therefore be given symbols, or as complex ones deserving
extra notational highlighting.  Nial uses all-caps for these 
"transformers" and all-lowercase for simple "operations".  But I would
rather read  +/^\' '=A  than  + REDUCE ^ SCAN ' ' = A .  In APL/! this
idiom would be written  +/.^.\.' '=A .  

Another operator of critical importance to APL, less so to extended APLs,
is rotate.  For example, to left-justify text: (+/.^.\.' '=A)-.A  where 
-. is the symbol for rotate.  This works on rows of a matrix, in parallel.
Perhaps rotate is sufficiently sophisticated that it should be a keyword;
but how do we decide?

I used as guideline another classic paper: Kanner, The Use and Disuse of
APL: An Empirical Study (APL'82).  "In general, 80% of all APL usage
[200 workspaces, 80,000 lines] occurred with 20% of the available function
set."  While this can be interpreted many ways, it would be abstract
nonsense to talk about the design of APL without consulting this or
similar studies.  I will summarize the two most important observations.

(1) Monadic functions, as percentage of all occurrences (approximate):
    rho      30%
    ,        20%
    iota     16%
    format    5%
    e-power   5%
    -         4%
    execute   4%
    not       4%
    (REST)   12%

(2) Dyadic functions, as percentage of all occurrences (approximate):
    ,        19%
    []       14%
    compress  8%
    +         8%
    take      8%
    rho       6%
    =         6%
    times     6%
    -         4%
    drop      3%
    not =     2%
    (REST)   16%

Certainly any ASCII rendition of APL has to look good on these!  
I picked slash / for rho; ! (upside-down i) for iota; # ~# for execute,
format; | ~| for take, drop; the symbol combination /. for compress
because it is less basic (its abundance is due to conditional-goto's)
and because its look-alike, reduction, is higher-order.  Simple math are 
straight ASCII + - * % ^ ; advanced math and logical operations are 
"dotted"; comparisons are "tilded" ~= ~< ~> .  In other words, most 
APL just fell into place.  

We can certainly discuss the specifics.  Perhaps everything "non-essential"
should be given keywords?


-- Bill Chang (wchang@cshl.org)           Cold Spring Harbor Lab., NY

p.s. By the way, I side with those who like brackets.  At 14%, the indexing
operation must be clear and concise; readability must take precedence
over abstract design.  (Now J's use of unbalanced brackets breaks with
tradition and typographical common sense, therefore it must be a 
deliberate attempt to confuse :-)
