ASCII APL (Submission to APL Quote-Quad) *LONG* 
Author Message
 ASCII APL (Submission to APL Quote-Quad) *LONG*

Renditions of APL as ASCII text: A Usenet comp.lang.apl discussion

          William I. Chang, Cold Spring Harbor Laboratory

                          30 June 1993

In response to Robert Brown's call for participation, I have prepared the
following excerpt of last year's ASCII APL debate.  If anyone feels I have
misrepresented his views, please contact me as soon as possible.  If there
are no serious objections, I plan to submit this excerpt to APL Quote-Quad
on Monday, July 5.

I have tried to delete _technical_ discussions that are J specific.  Also,
articles are re-ordered for the sake of continuity.  My renditions of APL,
APL/! and APL?!, are respectively the first and last articles in this series.

Please bear in mind that this material is more than a year old.  I also
apologize for the overuse of "smily" :-) in my articles.


Contributors:
  Purvis Bedenbaugh, Robert Bernecky, Edward M. Cherlin, Bill Chang,
  Leigh Clayton, LeRoy Davis, L.J.{*filter*}ey, John Gerth, David Gillett,
  J. Patrick Harrington, Roger Hui, Mike Kent, Daniel LaLiberte,
  Raul Deluth Miller-Rockwell, Steve Roy, Sam Sirlin

=============================================================================
Article: 1043 of comp.lang.apl

Subject: APL slash bang (Repost)
Summary: ASCII transliteration of APL
Date: Mon, 16 Mar 92 20:13:03 GMT

APL slash bang                                DRAFT 31 December, 1991

I would like to propose an ASCII rendition of APL, to be called
APL/! (a pun on APL\?, itself a pun on APL).  In this scheme, ASCII
symbol combinations that are visually appealing are assigned to
functions that are most commonly used, subject of course to rules
of consistency and operator ambivalence.  In particular, APL's two
Greek letters rho and iota are transliterated to slash / and bang !.
There are two adverbs, a pre-modifier tilde ~ signifying oppositeness,
and a post-modifier dot . signifying extension.  A longer note on the
motivation and design of APL/! will be submitted later.

Logical and Comparison:    
  ~. not   ^. and   v. or      ~^. nand    ~v. nor
  = equal  < less   > greater  ~= unequal  ~< not less  ~> not greater
Structural (shaping, slicing, transposing, shifting):
  , ravel, catenate   / shape, reshape   | take  ~| drop   \ transpose  
  -. reverse, rotate (row-wise)  +. (column-wise)
Special:
  ! initial segment of indices, index of   ? membership
  /. compress, reduce (cumulate)   \. expand, scan (partials)
  ~/. ~\. (column-wise)            # execute  ~# format
  (.f.) outer product   (f).(g) inner product
Arithmetic:  
  + plus   - negative, minus   * sign, times   % reciprocal, divide  
  ^ power  ~^ logarithm
Numerical:
  <. floor, min  >. ceiling, max   ~<. grade up  ~>. grade down
  *. factorial, choose   %. invert matrix, solve   ?. roll, deal

Syntactic:


  =. assignment   -> branch   <> statement separator   <>. o} comment
  & delta  &. delta-underscore   ~& del (define function)  ~&. lock
Unchanged:  
  ;  :  [ ]  ( )  '
Initials for Extended APL:
  c. enclose  ~c. disclose   o. box (objectify)  ~o. open

Some familiar idioms:
  /A "shape A"    //A "rank A"   (/B)/A "B-conform A"
  !10 "initial ten"    !/A "indices A"   B!A "B-indices A"
  ((!/A)=A!A)/.A "A minus duplicates"
      [indices A equal A-indices A, subset A]
  +/.^.\. "find first zero" [cumulative-add all-one left-partials]
  +/.^.\.-.' '=A "count trailing blanks"
      [find first zero, backwards, in space-equal-A]
  (-+/.^.\.-.' '=A)~|A "A minus trailing blanks"
  (-+/.^.\.-.' '=A)-.A "right-justify A"  
      [row-wise circular shift, trailing blanks to front]
  (!10)(.*.)(!10) "ten-by-ten multiplication table"
  A(+).(*)B "matrix product"   A(<.).(+)A "shortest paths, one stop-over"
  ->(COND)/LABEL [goto LABEL if COND]
  ->(CONDS)/.LABELS [goto LABEL corresponding to first true COND]

-----------------------------------------------------------------------------
William I. Chang, Ph.D.
Cold Spring Harbor Laboratory
100 Bungtown Road, Cold Spring Harbor, NY 11724

=============================================================================
Article: 1068 of comp.lang.apl

Subject: Re: APL slash bang (Repost)
Date: Thu, 19 Mar 92 17:25:16 GMT


Quote:
(Daniel LaLiberte) writes:
>I think the use of greek letters, heavy overloading, and character
>combinations in APL is a big mistake, and this mistake is only
>compounded by J and the proposed ASCII rendition of APL.

>There is little value in compressing the syntax of expressions to the
>extent that it is difficult for humans to read.  In contrast, there is
>value in compressing the semantics to higher-level operations.  Don't
>confuse the two.  I like APL for its semantics; its syntax sucks.

>The Lisp community has gone another route which makes a whole lot more
>sense to me.  Long, descriptive names are the norm.  It is false
>economy to reduce whitespace to the minimum required and save typing
>with short criptic names or non-meaningful symbols when large screens,
>visual editors, and completion techniques are available.

>Instead of yet another cryptic notation, what I want to see is a new
>ASCII based APL syntax that uses meaningful names for operators.  (It
>could also use commonly accepted precedence for numeric and logical
>operators (only) and left-to-right evaluation order, but this is not
>as big an issue.)

>Dan LaLiberte



Thanks for your reply!  You have stated your position very clearly
and tersely, much like a good APL program in my opinion :-)

Sure it is arguable whether succintness a la APL is a "disease",
but apparently enough of us like it that APL has managed to survive.
I like it because I can spend more time thinking instead of typing;
can fit an entire program on a sheet of paper so I can visualize
all the components at once; can read and write idioms more easily.  
Sure, in this age of large screens, macro expanders, etc. these
advantages may be less important than they used to be.  Still,
there isn't another language I would rather use.

I would agree though that greek letters and heavy overloading have
been mistakes.  I arrived at this conclusion as I spent several days
and nights "inventing" APL/! and thinking about translation among APL
dialects.  The short answer is, overloading makes automatic translation
impossible, at least in theory if not in practice.  Greek letters would
be acceptable to me were there no alternatives--but in my mind at least
APL/! (it really isn't that cryptic :-) is quite feasible, so why greek?  
(Yes APL symbols and keyboard are nice, but we all have horror stories
to tell...  I finally got everything working on my Mac, as a terminal
emulator, with capslock as APL toggle.)

It is trivial technically to give "names" to APL operators, and this
has been done many times.  The fact that no such scheme is actually
used by people suggests it doesn't work as well as one hoped.  There
is even a language Nial, rationalized APL so to speak, whose inventors
(Jenkens, Michel, More) were authorities on nested arrays as a "theory"
and gave careful thought to those names.  (I used to be able to prove
axiomatically important identities in this "language" of array theory,
so I think it is certainly feasible as a tool of thought if not quite
as a programming tool.)  Unfortunately the implementation of Nial was
not as refined (read: fast) as the theory, and Nial never caught on.

There hasn't been interest on comp.lang.apl in a serious discussion
on the future of APL.  Perhaps the time is now?


=============================================================================
Article: 1071 of comp.lang.apl

Subject: Re: APL slash bang (Repost)
Summary: Overloading and Ambiguity
Date: Thu, 19 Mar 92 22:02:51 GMT


Quote:
(Sam Sirlin) writes:

>Doesn't overloading include the use of "+" for scalars and arbitrary
>arrays? I wouldn't want to get rid of that. Are you objecting to cases
>like the use of "/" for reduction and compression?

I'm refering to using the same glyphs for related monadic and dyadic
operators.  First of all, some simply don't make any sense.  Why
sign/times, magnitude/modulo?  Is reciprocal necessary?  Etc.  But
the real cost of this is a syntactic and semantic ambiguity that
cannot be resolved except at run time.  An expression like
"FOO iota BAR" is inherently ambiguous--FOO can be a (global)
function or a free variable (defined in some calling environment) that
shadows such a function.  (This problem was examined in a classic paper,
Geroge Strawn, "Does APL require run-time parsing?" [Software P&E 1977]
in the context of syntactic analysis.  In practice, a later study showed
that complex flow analysis can resolve most ambiguities.)

The crusher is that this makes automatic translation among even similar
extended APLs theoretically impossible.  APL2 uses the up-arrow for
"first"; APL*PLUS and Dyalog APL, though similar to APL2, use different
symbols for the same thing.  There is no way in principle to tell ahead
of time whether an up-arrow in APL2 is "take" (in which case nothing
needs to be done) or "first" (which must be transliterated).  Of course
what this means is that APL vendors must reassign new glyphs to their
non-ISO operators, before there can be any hope of reconciliation.  
This problem all started because there were "too many" operators
and not enough symbols, or too many reserved words, etc., so APL glyphs
and overloading got invented.  Certainly I think it is time to make the
language simpler.  Unfortunately Iverson's philosophy, in APL or in J,
is quite the opposite.  

APL/! does nothing for overloading of ISO APL glyphs--it can't.  But
I would like to propose that extended APL operators be given "initials"
in the style of J, for example c. for enclose and o. for box (objectify).
This is so we can talk about these things unambiguously, and not too
verbosely.  It's about time we had an unambiguous translation of APLs
into a common alphabet.  And for comp.lang.apl that must be ASCII,
either as keywords or as transliterations.  The question is which is
easier to read and write.  My biased opinion :-) is that APL/! at least
has some of the flavors of APL.  ( ->COND/LABEL or ->CONDS/.LABELS :-)

Quote:
>|> It is trivial technically to give "names" to APL operators, and this
>|> has been done many times.  The fact that no such scheme is actually
>|> used by people suggests it doesn't work as well as one hoped.  There

>Actually I think people use them all the time (even here!). The fact
>that they're reinvented many times shows their necessity.

The question is would people use them if they didn't have to.  (I had
to just recently.)  Is a keyword-based APL still APL?

Quote:
>|> There hasn't been interest on comp.lang.apl in a serious discussion
>|> on the future of APL.  Perhaps the time is now?

>This is interesting, but how do we avoid the usual name calling that
>happens whenever the most important issue - generalized arrays - comes
>up?

>--
>Sam Sirlin


I think the abstract nonsense has to go away--we need examples of real
code.  Again, that means we have to agree on an easy to use, APL-ish,
preferably automatic, translation to ASCII.  Even better would be a
public domain, ASCII-based APL that incorporates the different dialects :-)

Thank you for your comments.  Please continue...


=============================================================================
Article: 1078 of comp.lang.apl

Subject: Re: APL slash bang (Repost)
Summary: Teaching APL
Date: Fri, 20 Mar 92 18:21:45 GMT


Quote:
(Steve Roy) writes:

>... I fail to see the point of reducing
>the whole suite of operators to every possible combination of
>punctuation marks...

>Come on guys, what is the point?

>Steve Roy


This is an exaggeration :-) just as it is an exaggeration to call J

punctuation mark; APL/! uses x x. ~x ~x. where x is taken only from
a small set of punctuation marks (except v. for "or" and other "initials"
for non-ISO APL operators such as c. for enclose; o. for box/objectify).  
Dot . signifies extension, tilde ~ signifies oppositeness.  There is
supposed to be some logic in the design :-)  

Honestly, I think such efforts as these _clarify_ the design of APL
to some degree, and may actually contribute to the teaching of APL.  
APL/! is described in a single page (typewriter pitch), with six
classes of operators (arithmetic; numerical; logical and comparison;
structural; special/APLish; and nested arrays) plus syntactic
constructs.  There is uniformity in letter combinations, across
operators of similar type or function.  In fact an operator's letter
combination _hints_ at its type.

Question: Does the use of letter combinations (of familiar symbols)
necessarily detract from the teaching of APL concepts, compared to the
use of special, unfamiliar symbols?

Question: Does APL/! _appear_ to suffer more or less, _compared to APL_,
from the "too many operators" syndrome?


p.s. Now J is more complicated (read: richer) but Iverson et al.'s original
APL\? (is it really APL\? or just APL? ? :-) specification fits in a
typeset page (two columns, rather small type).
=============================================================================
Article: 1094 of comp.lang.apl

Subject: Re: APL slash bang (Repost)
Summary: Semantic Differences
Date: Mon, 23 Mar 92 14:09:55 GMT


- Show quoted text -

Quote:
(John Gerth) writes:
>From an historical perspective I can't really see that dumping the
>symbol set in favor of ASCII would necessarily do much for easing
>the task of automatic transliteration among dialects.  Language
>designers might just as well seize on the same keywords for semantically
>different concepts as they did on the same symbols.  If I remember
>correctly, all of the generalized array approaches had a function  
>called "enclose" to start with.  Then semantic differences led to
>qualifications in the literatature to "strict", "permissive", etc.
>It was relatively late into the fruitless and tragic APL War of the Roses
>that "box" came along.

>Even among relatively similar dialects this can happen.  I distinctly
>remember a visit by Bob Smith (designer of STSC's NARS system) to
>reconcile with Jim Brown its differences with APL2 and, of all
>things, there was no agreement about the definition of the result
>of the "depth" function.  The debate was cordial, but in the end
>no one was convinced and the two system went on separately.  Although
>it cannot be proven, I believe the result would've been the same
>if the function was literally spelled "depth" instead of symbolically
>represented by the monadic use of the equivalence triple-bar.

>Anyway, there's plenty of good debate in the ASCII v. symbol discussion
>without this sidetrack.

>--
>/John

Thanks for the sidetrack.

I agree semantics is the real problem.  And economics.  It is far from
clear that APL vendors would benefit in the short run from a reconciliation.  

The only way to do this is for a committee of users to decide on the names.
Since there are so few good names, the assignments have to be impartial.
That's why I'm endorsing "initials": c. for enclose, o. for box/objectify
(at least both look good).  Now the real situation is much more complicated.
(A fundamental disagreement on types is whether or not '' equals iota 0.  
The two ='s must be given different names.)  I don't know if _all_ the
differences can be "resolved" by giving them different names/abbreviations/
initials; where can I find a comprehensive list of these differences?

I said earlier that each company must invent new, unique symbols and rename
all their non-ISO features in these symbols.  Then there will be less
confusion on paper at least.  In order to use or to talk about these symbols
on the net for example, an ASCII solution must be devised.  Hence APL/!.

I do believe glyphs are important, and _personal_ glyphs will hopefully
be incorporated into the next generation of (notebook/pen-based) computers.  
(Chinese has thousands of glyphs; the language is very rich :-)  Now APL
has a head start in this regard!  But for the next five years at least,
we need a stop-gap measure to foster discussions and the teaching of APL.
Without such efforts APL will not survive...


=============================================================================
Article: 1095 of comp.lang.apl

Subject: Re: APL Transliteration (was Re: APL slash bang (Repost))
Summary: Compilation Assumptions
Date: Mon, 23 Mar 92 15:15:11 GMT


- Show quoted text -

Quote:
(Raul Deluth Miller-Rockwell) writes:
>Bill Chang:
>   I'm refering to using the same glyphs for related monadic and
>   dyadic operators.  ... But the real cost of this is a syntactic and
>   semantic ambiguity that cannot be resolved except at run time.  An
>   expression like "FOO iota BAR" is inherently ambiguous--FOO can be
>   a (global) function or a free variable (defined in some calling
>   environment) that shadows such a function.

>And strand notation makes this problem 10 times worse...

>But it's not that hard to resolve the problem, even _with_ strand
>notation [which I'm not arguing for, but am using as a worst case]:

>[A] It can be assumed that all names which have current definitions
>will continue to have that definition in the future.

>[B] It can be assumed that all names which are assigned [in an
>explicitly defined function] will always have the properties of that
>assignment.

>[C] It can be assumed that if the programmer wants some other behavior
>(s)he can make an explicit interpreter call.

>These rules only apply to compiling well-written programs.
>Transliteration of dusty deck programs [which may be very badly
>written] is another problem entirely.  Probably the best thing to do
>in this circumstance is run the program under an emulator to collect
>statistics about the program -- and feed this statistical information
>into a compiler.  But there's no single solution to badly written
>code...

>--


Thanks for the note.  Undoubtedly simplifications such as these must be
made when one wants to _compile_ APL.  Global flow analysis will also
help.  (Weiss & Saal in APL'81: empirically 32 workspaces containing
697 functions, 8593 lines, are successfully parsed; only 8% of names
are neither global nor strictly local, hence requiring inter-procedural
data flow analysis.)

But surely these restrictions are too severe if one wants only to
transliterate among similar APLs.  And the inherent ambiguity is a
major stumbling block.

Suppose function F has a local variable X and calls G, which has a free
variable X, not assigned-to in G.  The interpretation of "X up-arrow Y" in G
should not depend on the global definition of X.  (In APL2 monadic up-arrow
is "first".)  How does one parse or transliterate G without knowing F calls G?

(Please allow me to be somewhat pedantic about this, for my own benefit
and for any APL neophyte who may be reading...)

This is how programs are written in APL.  No local functions, only
two arguments permitted.  Dynamic scoping becomes the glue that ties
functions together, and this complexity is made worse by "ambivalent"
operators and functions.  It is easy to criticize APL in this regard,
but consider: lexical and static scoping are out because in the APL
workspace there is no concept of "nearest definition" of free variables
(unlike script-based J, which has its own ideosyncracies with "loading
order").  The APL workspace is elegant and obviously good enough for
people to get real work done.

Dynamic scoping is also good for controlling complex states.  An example:


would use the new parameters only for the duration of the call; its change
of state is handled simply and elegantly.  Short of having true object
orientation, dynamic scoping is arguably superior to static scoping in
this regard.  (See a classic paper, Steele & Sussman: The Art of the
Interpreter or, The Modularity Complex, MIT AI Memo No. 453, May 1978.)

But ambiguity from ambivalent functions we can do without!

By the way, local functions _are_ possible in APL (there's even a paper
in APL'91 on the subject) and I use them all the time.  Most of the time

the calling function F if F has been changed since G was defined.  To get
true local functions, the name G has to be localized in F (i.e. appear

APL2...  Would they work in ISO APL?)

Boy we've had a lot of action this past week...  Let's keep it up.
How about packaging a summary of the various threads and sending it to
APL Quote-Quad?


=============================================================================
Article: 1111 of comp.lang.apl

Subject: Re: APL Transliteration (was Re: APL slash bang (Repost))
Summary: Regarding J
Date: Tue, 24 Mar 92 20:58:46 GMT


Quote:
(Raul Deluth Miller-Rockwell) writes:

[text re: J deleted]

Quote:
>   Short of having true object orientation, dynamic scoping is
>   arguably superior to static scoping in this regard.

>'true object orientation'?  I'm not quite sure what you mean by that
>phrase, but I'd argue that J's implementation of nested arrays is
>adequate to meet the needs that dynamic scoping fills in current APLs.

In an object oriented system like Smalltalk, the "caller" sends a
message "do so-and-so with such-and-such parameters" to the "callee".
The parameters that are sent can be a subset of those actually needed;
the rest are taken from the "callee" object's state.  This mechanism
has been simulated using nested arrays for messages (recent conferences).

[text re: J deleted]

Quote:
>   But ambiguity from ambivalent functions we can do without!

>That, I think, is going to have to wait till we get a larger symbol
>set...

You can't be serious :-)  J has more symbols (complex ones) than APL;
they all got filled with functions.  In fact, there are (I think) six
functions associated with each ASCII letter or punctuation: monadic
and dyadic x x. x: (perhaps not all are taken at the moment).  That's
a lot of functions.  

We could have had more adverbs x; x! x? etc. instead of overloading.
But this is just another of Iverson et al.'s design decisions: to be
maximally comprehensive.  Why would an even larger symbol set make any
difference?  

I'm afraid we are treading into deeper waters...  These are basic
issues in the design of programming languages, and there are tradeoffs
with each method, perhaps too difficult to discuss on Usenet.

[text re: J deleted]


=============================================================================
Article: 1138 of comp.lang.apl

Subject: Re:      APL Transliterations (and parsing)
Summary: Operators and functions
Date: Fri, 27 Mar 92 03:25:17 GMT



- Show quoted text -

Quote:
>Restricting all functions to a fixed valence won't cure all parsing problems,
>because of operators. Consider: f g A, where A is an array. This can be parsed
>as

>    monadic-function monadic-operator array

>or  monadic-function monadic-function array

>even if f and g are know to be monadic. Making all functions and operators
>dyadic would help though.

>(A cure for this is described in my paper "Operators considered harmful",
>APL Quote Quad, Vol. 17, No. 1 and in my APL'88 paper "A framework for
>extensions of APL". (However, that solution is not compatible with APL,
>(and looks Lispy))).

>/Martin

I don't think this would be a problem for transliteration.  As for parsing,
could not  g A  be considered a unit, regardless of g's type?  I.e. a monadic
operator g applied to an array A is a special "curried form" that is passed as
argument to a function f.  (We won't know g A's type until run time.)


=============================================================================
Article: 1098 of comp.lang.apl

Subject: Re: Expressiveness of Language
Summary: Essential APL?
Date: Mon, 23 Mar 92 20:00:55 GMT


- Show quoted text -

Quote:
(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



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?


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 :-)
=============================================================================
Article: 1106 of comp.lang.apl

Subject: Re: Expressiveness of Language
Summary: Why do I like those special characters?
Date: 24 Mar 92 04:53:24 GMT

   ..many things, from which I pick a couple of points just as an excuse
to put in my 2 cents worth:

Quote:
>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.  
>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 :-)

   It has been interesting to follow this discussion on APL (& J)
notation. After posting a while back about my distaste for the ASCII
notation of J, I have been wondering why I feel that way. The reasons
for a pure ASCII approach are obvious - so why is the result unpleasant?

   I am not a programmer, let alone an APL programmer. I am an astronomer
who writes programs to calculate various things. I started with fortran
in the 60's, and most of my code is still in that language for backward
compatibility. When I write a production program from scratch now, I tend
to use C instead. The control structures look nicer. So what about APL?

   For me, APL is the language of choice for quick calculations, as well
as for prototyping something that will later grow into a C program that
will run for hours. And I will stick with APL until speed forces me to
abandon it. Used in this way, it is essential that you be able to move
data back and forth between APL and other languages. I have been using
Dyalog APL, which has auxiliary processors that write and read unix files
so that this sort of data exchange is not a problem.

   But back to notation. I guess I think visually. I want to see the whole
program or at least subroutine on one page if possible. To take it in at
a glance. And that is why, even though it takes three keystrokes to type
an overstrike character, I would rather have that than a two-character ASCII
combination - better the iota than "i.", and what could be more expressive
than <- ? And the special symbols are free of the distracting (if subliminal)
connotations of ASCII characters. I always want to duck when I see "!", I am
puzzled by"?" and have to look all over for the other half of "{" or "[".
Maybe I will get over that if I continue to play with J, but I'm not sure.

   For now, APL is something to use, and J something of a riddle - it should  
be as powerful as APL, but how do you even translate your APL phrases into
this strange stuff? Thus I wanted to look at a particular value in an array,
but in the Iverson books didn't seem to have the equivalent of the [ ..] index.
(And if your arrays are say, 4 x 500 x 800, you don't just look at the whole
object!) So you try to figure out what to do. Worse yet, all the indexing is
origin 0. (*IS* there a way to set the J index origin to 1? I.e., so that
"1{z" would get the first element of z rather than "0{z"?)

   What I finally did was define


Then, where in Dyalog APL I would type,

               z[2;3;1]
I can use
              2 3 1 I z
in J. Or, for
    z[1;;]   I have  1 I z , etc.

   But when you have to struggle to do things like this ... will it ever
catch on? Will even APL survive? I think it will, but perhaps not as APL.
Look at the evolution of FORTRAN, where the control structures have been
added on the model of C or Pascal. The idea of arrays as objects carrying
their dimensions with them, to be manipulated without all those stupid
do-loops and error-prone indices is just too ...useful... to be ignored.

   Astronomers are starting to make a lot of use of IDL (Interactive Data
Language), which one tends to think of only in terms of image display and
manipulation. But guess what, folks. Images are arrays of numbers, and in
IDL you can add, multiply, etc. these arrays without any reference to
indices, just like APL. And IDL is not just a display language, but a full
programming language - and some people here have it churning away for hours
on Sun SPARCs, and claim that it's not that much slower than FORTRAN, and
ever so much more interactive and faster to program - sound familiar? So,
though I would hate to see it, APL may vanish when it's useful features are
are silently incorporated into the next generation of higher level languages.

                                                  Pat Harrington

=============================================================================
Article: 1128 of comp.lang.apl

Subject:      Re: Expressiveness of Language
Date:         25 Mar 92 19:00:07 UT

     Pat Harrington wonders about setting the index origin to 1 in J.

     My question is:  why?  He says that he uses APL mainly for developing
stuff that he will rewrite in C, in which all indexing uses origin 0, and so
I wonder what he would gain from such a (mis?)feature.
     APL (versions that I have used) allows such a setting, and as a result
I've seen plenty of code that expends effort on origin-independence, or
localizes []IO 'just in case'.  I've seen collaborative code break in
mysterious ways because the team members had theological differences over this
issue.
     There is a discontinuity in APL between the units used by take/drop, which
do not depend on the origin, and the units used by indexing, which does.  J's
scheme unifies these, resulting in merge/select semantics which are both
simpler, in that they are more unified, and more powerful, in that they are
more general.  A fixed index origin of zero seems, to me, a small price to pay.

     Pat also makes a passing mention of Pascal, which goes to the opposite
extreme of allowing the index origin to take many more values than zero and
one.  But in Pascal, there is not a single origin, but one for every array,
and there are no 'index' operations (such as APL's monadic iota) which are not
bound to some array.  This flexibility of index origin sticks out as something
of an anomaly in a language where most primitives are strictly scalar, and
arrays are something less than first-class entities.
     It's my experience that this origin-flexibility of Pascal's is rarely
used.  It's possible that programmers would find more use for it in a language
which was more array-oriented, but I think it's equally likely that the cases
where it is helpful are quite rare.  I certainly wouldn't want to try and graft
a wart like that onto APL or J on the off chance that somebody might find a use
for it....
                                      Dave Gillett
=============================================================================
Article: 1167 of comp.lang.apl

Subject:      Re: Expressiveness of Language
Date:         30 Mar 92 21:00:07 UT

Quote:

>     There is a discontinuity in APL between the units used by take/drop,
>which do not depend on the origin, and the units used by indexing, which does.
>J's scheme unifies these, resulting in merge/select semantics which are both
>simpler, in that they are more unified, and more powerful, in that they are
>more general.  A fixed index origin of zero seems, to me, a small price to
>pay.

To which Bill Chang replied:

Quote:
>Could you describe merge/select for those of us who don't yet know J?  Thanks.

     Not very well; certainly not as well as several of the others who post
here....
     But I can at least explain what I mean.  In APL, x[1] is sometimes the
first element and sometimes the second, depending on []IO, but 1 ^ x is
*always* the first element.  That's the discontinuity:  the numbers used to
refer to part of an array have different semantics.
     In J, index 0 is always the first element.  Indices 1, 2, 3, etc. have the
obvious semantics of origin-0 indexing, and indices -1, -2, -3 have the
take/drop-like semantics of 'wrapping around' to the end of the array.  A
given index *always* refers to a specific position in the array, and (for some
n) all integers from -n...0...+n map to specific positions in the array.  (I'm
not sure whether J allows this interval to cover the entire span of integers,
wrapping as necessary (which has a certain mathematical appeal), or whether n
is the size of the array (which would probably catch a certain number of
programming errors).)
     Allowing origin variation breaks the 'constant reference' property of
indices.  Allowing origin 1 breaks the 'contiguous interval of integers'
property, by making index 0 anomalous.  It is these semantics of the indices,
rather than the syntax/semantics of merge/select, to which I was referring.

                                       Dave Gillett
=============================================================================
Article: 1145 of comp.lang.apl

Subject: Re: Expressiveness of Language
Summary: Index Origin
Date: Fri, 27 Mar 92 15:09:11 GMT

[text re: J deleted]


p.s. I prefer origin zero, for "theoretical" reasons but also because I can
ignore the - in  ->LABEL-iCOND , but not the x in  ->LABELxiCOND  (i is iota,
to be read "IF"; x is times).  Also  ->iCOND  is conditional exit in origin 0.
Now with C being prevalent, origin zero seems obvious, but back then it was
counter-intuitive for a lot of people.
=============================================================================
Article: 1079 of comp.lang.apl

Subject: Expressiveness of Language
Date: Fri, 20 Mar 1992 18:42:05 GMT
Lines: 68


 (1)--------------------------------------------------------------------
 |   I think the use of greek letters, heavy overloading, and character
 |   combinations in APL is a big mistake, and this mistake is only
 |   compounded by J and the proposed ASCII rendition of APL.
 |
 |      .... more on the general subject of reducing the number of
 |    keystrokes being a silly goal at the expense of readability ...
 + ---------------------------------------------------------------------


 (2)---------------------------------------------------------------------
 |   Absolutly, positively correct.  I fail to see the point of reducing
 |   the whole suite of operators to every possible combination of
 |   punctuation marks.  Is this really supposed to be a language for
 |   Stephen Hawking, who is forced to "type" at less than a character per
 |   second?
 |  
 |   Come on guys, what is the point?
 + ---------------------------------------------------------------------


 (3)--------------------------------------------------------------------
 | The "point" is (to quote Kenneth Iverson):
 |
 |    "Applied mathematics is concerned with the design and analysis of
 |     algorithms or PROGRAMS.  The systematic treatment of complex algorithms
 |     requires a suitable PROGRAMMIWNG LANGUAGE for their description, and
 |     such a programming language should be concise, precise, consistent over
 |     a wide area of application, mnemonic, and economical of symbols..."
 |
 | This is the introduction to "A Programming Language" and shows that the
 | "greek" characters are mathematical in origin.  The conciseness is that of
 | mathematical ideas.  Yes, I could write 5+5+5, but that is interchangeable
 | with 3x5.  The "point" is to have a language that readly facilitates the
 | manipulations of mathematical ideas.
 + ---------------------------------------------------------------------

I agree with Mr Davis and Dr.Iverson.

The opinions expressed in quotations (1) and (2) appear to be dominated
by lack of experience.  Those who have studied higher mathematics,
APL, or J, will have learned the power of expressiveness of notation
used in these languages.  In particular, the "silly goal" mentioned
above, is not to find just the minimal number of strokes to express
ideas, but to be able to solve larger problems.  To Davis's quotation
of Iverson, I would like to add these two, which come from a philospher
and from the the builder of a computing engine.

      By relieving the brain of all unnecessary work,
      a good notation sets it free to concentrate on
      more advanced problems, and in effect increases
      the mental power of the race.
                                       A.N. Whitehead

      The quantity of meaning compressed into small
      space by algebraic signs, is another circumstance
      that facilitates the reasonings we are accustomed
      to carry on by their aid.
                                       Charles Babbage

--
Leroy J.{*filter*}ey, Faculty of Mathematics, U of Waterloo, Canada  N2L 3G1



=============================================================================
Article: 1082 of comp.lang.apl

Subject: Re: Expressiveness of Language
Date: Fri, 20 Mar 1992 23:32:38 GMT



Quote:
>   The opinions expressed in quotations (1) and (2) appear to be dominated
>   by lack of experience.  Those who have studied higher mathematics,
>   APL, or J, will have learned the power of expressiveness of notation
>   used in these languages.  

I'm familiar with the power of expressiveness, and indeed APL and J
are powerfully expressive in the sense of condensing much semantics
into a small space.  (APL was my first language, almost 20 years ago.)

The problem isn't the compression itself, it's (in part) the
inappropriate medium of linear ascii text.  Mathematical notation,
which Whitehead and Babbage were referring to, has long ago branched
into 2 dimensions and the use of visual, iconic, or graphical
notations to help the reader perceive the relationships between
components.  In fact, it is important to carefully typeset (in the TeX
sense) mathematical notation to give it that clean look that lets the
reader transcend the medium to get the message.

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.

         By relieving the brain of all unnecessary work,
         a good notation sets it free to concentrate on
         more advanced problems, and in effect increases
         the mental power of the race.
                                          A.N. Whitehead

Excellent quote, but what is the "work" we are talking about here?
The initial learning curve is one thing, but I'm not too concerned
with that as long as it isn't too steep, and the height achieved makes
it worth while.  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.  The density of notational noise in those
languages is about as much as most people care to see.  A language
like Perl has gone too far in my opinion.

One important problem for an APL notation (to remain anything close to
the original APL concept) is to treat user defined functions in the
same way as infix and prefix operators.  Smalltalk has relevant ideas
here.  Functional languages have ideas for notations of operating on
functions as objects.

Dan LaLiberte


=============================================================================
Article: 1099 of comp.lang.apl

Subject: Re: Expressiveness of Language
Date: Mon, 23 Mar 92 20:38:52 GMT


Quote:
(Raul Deluth Miller-Rockwell) writes:
>To address some of the comments I've seen in this newsgroup in the
>last couple days...  If you wish to guarantee that a function is only
>used monadically, you can use
>        fn : ''

>Likewise, if you wish to guarantee that the function is only used
>dyadically, you can use
>        '' : fn

[text re: J deleted]

There appear to be (at least) the following philosophies:
(1) APL and its glyphs should be preserved; ASCII renditions are
    too foreign or too difficult to read to be worthwhile.
(2) APL is too big and too terse; a few keywords are better than
    lots of seldom-used symbols.
(3) APL needs improvement, and while we are at it may as well make
    it richer and more compact.  J is the result.
(4) J is great but too complex; translating to keywords would help.
    Kind of like John Backus' functional language FP--not human-
    readable but ought to make a good target for compilers.

The amazing thing is, these differences are mostly syntactic.  
Can't there be some compromise?  Let's try to find a middle ground
everybody can live with, so we can at least talk and be understood.  
Fix the notation/keywords/whatever.  If we can't even agree on
this rather trivial matter, how can we hope to tackle real, semantic
differences among extended APLs?


p.s. A positive note: ten years ago the LISP community was divided
into MacLISP and InterLISP camps.  Now there is only CommonLISP.
=============================================================================
Article: 1105 of comp.lang.apl

Subject: Re: Expressiveness of Language
Date: Tue, 24 Mar 1992 04:15:54 GMT

[text re: J deleted]

Bill Chang:
   There appear to be (at least) the following philosophies:
   (1) APL and its glyphs should be preserved; ASCII renditions are
       too foreign or too difficult to read to be worthwhile.

I see that as two independent statements.  I agree with the first
statement (APL and its glyphs should be preserved).  I disagree with
the second (ASCII renditions are too foreign or too difficult to read
to be worthwhile).

   (2) APL is too big and too terse; a few keywords are better than
       lots of seldom-used symbols.

Here, the first statement appears to be contradictory.  Also, I'm not
sure why the choice implicit in the second statement needs to be made.

   (3) APL needs improvement, and while we are at it may as well make
       it richer and more compact.  J is the result.

Here, I see three statements.  I agree with the first, APL needs
improvement [well, let's just say that the implementations available
to me could use improvement].  If I understand what you mean by
"richer and more compact", I'd say that those _are_ some of the
improvements.

Finally, I disagree with your third statement.  While J is an improved
version of APL, it isn't "the result".  J could use some improvement
as well.  J is _a_ result.

   (4) J is great but too complex; translating to keywords would help.
       Kind of like John Backus' functional language FP--not human-
       readable but ought to make a good target for compilers.

J isn't all that complex.  STSC's PC APL I/O facilities are complex.
J is a model of simplicity in comparison.

But I'm not sure why you'd want to make J a target for compilers.
Current implementations aren't all that fast.

   The amazing thing is, these differences are mostly syntactic.

I have a major disagreement with this one.

There are some strong semantic differences involved as well.  These
appear to be syntactic only if you do not execute the code.

Finally, here's my way of resolving choices among the 30 or so
available aliasing schemes for APL:  pick whichever seems to be
handiest for the problem at hand.

In other words, if I want to present executable code of a non-trivial
nature, I go with J.  Versions of J are available to most of the
people on internet.  And J is complete enough as a language that I can
usually write what I want to write.

If it's important to capture the VS-APLNESS, or the APL2-NESS of a
problem, I go with visual puns, or I try to spell out the names of the
various symbols in as unambiguous a fashion as possible.

--

=============================================================================
Article: 1101 of comp.lang.apl

Subject: Re: APL slash bang (Repost)
Summary: Short reply
Date: Mon, 23 Mar 92 21:37:26 GMT


Quote:
(Sam Sirlin) writes:


>I agree entirely about an ASCII version of APL symbols, and have my
>own version - really just a generalization of the existing efforts
>(samples of most of which are available from waterloo). Lee{*filter*}ey,
>John Mitloehner and I have been kicking various ideas around regarding
>this and porting workspaces - John has a paper at APL 92. I'll
>probably post a newer version of my ideas soon...

I'm curious how you are handling the problem of syntactic and semantic
ambiguity due to ambivalent functions (see several postings floating
around).  Or do you simply ask users to use cover functions?

Quote:
>Regarding APL\!, it's certainly APLish in its compactness, but I'm not
>sure that's desirable for an ASCII version. Especially the uses of !,
>/, \, and ? for non-obvious functions different from their standard  
>definitions. If the standard APL symbol is available in ASCII, why not
>use it the same way?

Once we did that, the rest of the design becomes so constrained that
we end up going to a larger set of symbols (the ugly ones :-).  The
result suffers.  I'll admit I agonized over this, but decided $ or
/. for rho (hence $$ or /./. for rank) is too high a price to pay
for this mostly illusory "compatibility".  Why waste perfectly good
symbols ! and ? on factorial and roll?

Quote:
>... Things like ~#. require memorization of yet
>another set of glyphs...

Well, # is execute and ~# is format, so #. for decode and ~#. for encode
are their less popular cousins.  Not all APL operators are equally
important; some must be given combinations (or keywords as you suggest).

Quote:
>... this "word" style would also be less intimidating to non-APLers than
>your cryptic version - those I've shown J have been similarly
>intimidated.

I am not surprised! :-)  Please show them APL/! :-)

(Is there a rule regarding . versus : as adverbs?)

Quote:
>... I think that one cryptic character per "function" (APL)
>is actually less intimidating than 2 or 3 (J or APL\!), even if the 2
>or 3 are ASCII.

This is probably true.  Unfortunately we sometimes can't have APL glyphs.
The design principle of APL/! is that the most commonly used operators are
given the best-looking symbol combinations--single letters if possible
(hence / ! | ~| for rho, iota, take, drop; please see another note I posted).

(Actually in APL it's one cryptic character per _pair_ of functions.)

Quote:
>... I think that in addition there are alot of characters
>you've left out that exist in various quad AV's - various overstrikes
>of the ISO APL set that may be distinct to a particular dialect, for
>example hoof and squish quad. Since noone can know just what someone
>will decide to use, I think an ASCII version should include provision
>for describing overstrikes. I suggest .ov or .overstrike.

I think this really isn't a language but an I/O problem.  As for non-ISO
operators, I endorse "initials" (abbreviations in the style of J).

Have I earned even one convert yet? :-)


=============================================================================
Article: 1112 of comp.lang.apl

Subject: Re: APL slash bang (Repost)
Date: Tue, 24 Mar 1992 21:53:09 GMT


|> I'm curious how you are handling the problem of syntactic and semantic
|> ambiguity due to ambivalent functions (see several postings floating
|> around).  Or do you simply ask users to use cover functions?

The purposes of my effort are:

1. I love the APL glyphs and want to keep them.
2. They are generally unavailable outside an APL interpreter - file
   manipulations (editing, email, news, reading by other programs) are
   generally done in the printable subset of ASCII (is EBCDCK dead? I
   presume one can convert in and out of this easily?).
3. Different APL's have different conversions from bits to APL glyphs,
   and even different sets of glyphs.
4. If I like it I'll modify: aplc and the Finish TeX system to use it,
   write some functions in various dialects to get in and out.
(5. J is neat too.)

Hence I'm not starting from scratch to design a new meta-APL that
handles all dialects. Not that this isn't a worthy goal, but it's a
big job. I'm also not going to worry about different dialects
different use of the same symbols - I think there are relatively few
cases of this (notably uparrow). Most ambivalent glyphs can just use
the glyph name (as opposed to the function name), for example .ro or
.rho . The interpreter (or compiler) has to deal with this anyway. TeX
only cares what the symbol looks like. In the cases that matter (e.g.
first), I think the business of translating from (say) APL2 to Sharp
dialects probably has to be done by hand anyway. A good argument for
not using nested arrays of any flavor till there's a standard.

|> for this mostly illusory "compatibility".  Why waste perfectly good
|> symbols ! and ? on factorial and roll?
Well Iverson already did (:-)!

|> (Is there a rule regarding . versus : as adverbs?)
Do you mean in J?

|> (Actually in APL it's one cryptic character per _pair_ of functions.)
In general, I like the standard pairings. In most cases they make
sense.

|> I think this really isn't a language but an I/O problem.  

Indeed, that's what I'm addressing, the treatment of APL outside and
from and to the APL environment, rather than redesigning the language.

|> As for non-ISO
|> operators, I endorse "initials" (abbreviations in the style of J).

Sounds reasonable, but there are alot of them (even every flat
implementation has some).

--
Sam Sirlin

=============================================================================
Article: 1124 of comp.lang.apl

Subject: Re: APL slash bang (Repost)
Date: 26 Mar 92 03:15:14 GMT

Well, I want to take one more whack at rephrasing this because I think
there are two largely independent questions here which you don't want
to get muddled up together at this stage.   The first one is to come
up with an ASCII-only scheme for APL notation.   The second question
is transliterating among APL dialects.

The second problem is, IMHO, a lot harder than the first and may well
not have a clean solution even if you find separate clean solutions
for each dialect.  Furthermore after discovering that unifying proposal,
obtaining consensus is, as Bob points out, not necessarily a rational
process (I saw some pretty humorous things in my two years on that committee).
I know none of us thought it'd be a decade to get the first standard done.
The best standards are those made "de jure" by ratification of "de facto"
ones from the market place in recognition that the case is closed.

Dealing with the extended systems is very tough.  Which of the competing
definitions will be anointed with the names for "reduction", "scan",
"inner product", and "outer product" -- since the semantics of all
are intertwined you have to do them all together.  And you can't tell
from the original APL - all the extensions have proper projections
of their semantics onto the common ancestor much as a variety of
solid objects may cast the same shadow on the plane.

 /John
=============================================================================
Article: 1122 of comp.lang.apl

Subject: Re: APL slash bang (Repost)
Date: Tue, 24 Mar 92 16:15:12 GMT


Quote:

>I agree semantics is the real problem.  And economics.  It is far from
>clear that APL vendors would benefit in the short run from a reconciliation.  

>The only way to do this is for a committee of users to decide on the names.

{Long pause while I guffaw, giggle, and roll on the floor laughing}.

Spoken with true naivety. Two points, which should be obvious:
  a. Committees are incapable of doing anything which comes even close
     in sensible design to that of a single person.
  b. Go sit on a standards committee, if you want to see this silliness
     in action. You will not (see below) see any form of sensible
     behavior, let alone impartiality.

     Here was a typical event at the ISO APL Standards Committee Meeting:
      -I talk about some point, and suggest that we discuss it until
       we have some statement about which we can reach consensus.
       I think the point in question had to do with the original topic
       here: Differing semantics among vendors, for the same glyph.
      - By mutual agreement, we claim to have reached consensus.
      - I introduce the motion we have hammered out.
      - The French vote against it.

Quote:
>Since there are so few good names, the assignments have to be impartial.
>(at least both look good).  Now the real situation is much more complicated.
>(A fundamental disagreement on types is whether or not '' equals iota 0.  
>The two ='s must be given different names.)  I don't know if _all_ the

Sorry, big fella. Since the result of ''= iota 0 is an empty array,
there are no result elements involved, so the point is moot. Perhaps
you meant "match"?

Quote:
>differences can be "resolved" by giving them different names/abbreviations/
>initials; where can I find a comprehensive list of these differences?

Nowhere.

Not in one place, anyway.

Quote:

>I said earlier that each company must invent new, unique symbols and rename
>all their non-ISO features in these symbols.  Then there will be less
>confusion on paper at least.  In order to use or to talk about these symbols
>on the net for example, an ASCII solution must be devised.  Hence APL/!.

Nope. Won't work.
For example, the definition of reduction differs between SHARP APL and APL2
(and I think, between APL*PLUS and APl2, but ain't sure). Meetings between
vendors, as you have seen by Gerth's message, have little effect.
Why? Because BOTH vendors have tens of thousands of users with gigabytes
of code which is dependent on the current behavior of that system.
What's in it for them? (This isn't always the case -- a number of us
have made significant improvements in bringing different dialects to
a common lingo, but it's nowhere near as easy as you present.)

Quote:
>I do believe glyphs are important, and _personal_ glyphs will hopefully
>be incorporated into the next generation of (notebook/pen-based) computers.  
>(Chinese has thousands of glyphs; the language is very rich :-)  Now APL
>has a head start in this regard!  But for the next five years at least,

Yup, it's got thousands of glyphs. And it's a {*filter*} to type.


Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9
Canada
=============================================================================
Article: 1123 of comp.lang.apl

Subject: Re: APL slash bang (Repost)
Date: Wed, 25 Mar 92 22:56:13 GMT

I'll keep this reply short :-)



Obviously the task (whatever it is) isn't easy.  Obviously, the composition
of past standards committees leaves much to be desired.  (No :-)

I happen to think we have made real progress in just one week, and if
enough of us contributed we can reach a compromise, one that is good enough
for comp.lang.apl at least.


=============================================================================
Article: 1142 of comp.lang.apl

Subject: Re: APL slash bang (Repost)
Date: Fri, 27 Mar 1992 07:56:55 GMT



 > ... the definition of reduction differs between SHARP APL and APL2
 > (and I think, between APL*PLUS and APl2 [sic], but ain't sure).

Reduction is in theory the same in APL2 and APL*PLUS.  I have seen
differences in the result of   f/   (using both off and on since 1981)
only when the semantics of   f   differ between the dialects.  As STSC has
taken conformance with APL2 as a stated direction, I would expect these
differences (which are ina any case related to the function operand
rather than to the operator) to disappear in the fullness of time.
=============================================================================
Article: 1155 of comp.lang.apl
Subject: Re: Expressiveness of Language

Date: 30 Mar 92 01:04:02 GMT

In LISP, you can write your own syntax analyzer, but in APL you can't do that
in an obvious way. LISPers don't rwar so much about syntax; they use what they
like. There are several ways around this problem. Iverson, Alan Graham, and
others have written APL systems with extensions that translate to APL, where
the user can redefine both syntax and semantics. J is a good base for such
experiments. I don't care very much; I have used I-APL transliteration, APL*
Plus transliteration, and a large number of incompatible APL systems. All of
the syntaxes are usable, and I am more concerned about semantic differences.
Rather than argument, I would like to see implementations. Then anyone who
cares can try out the alternatives.
=============================================================================
Article: 1129 of comp.lang.apl

Subject:      Demise of the non-ASCII character set
Date:         25 Mar 92 22:45:21 UT


death of the APL character set.

 Don't despair, it has never been so healthy. The APL character set will be
part of IS 10646, and hopefully we'll manage to get it into Unicode too (pity
the US can't use the international standard, but that's another gripe). The new
standards for displays (X, Sunview, and Windows) all allow user fonts, TeX
supports APL fonts and so does postscript. In fact, the current state of
affairs is that you can get an APL font basically anywhere you want one with a
little effort (sometimes more than a little) as long as you're using modern
equipment.

 Throughout APL's life its symbol set has been attacked, and I doubt this will
change, even when there are no operating pieces of equipment that can not use
it. It's a cultural thing. I was told once (by Joey Tuttle, I think) that he'd
had an oriental person tell him that he thought APL was remarkably easier to
use than other languages, because of all the nice symbols. We are more used to
invariant symbols combined in new ways than to new symbols, but for most people
that's a quickly passing phase. Of course, you still have to get them to expend
the effort, but I doubt the symbols are in reality a serious component of that
problem, at least in most cases. The 'non Computer Science' form of the
language (by which I mean it doesn't conform to current ideas about control
structures, typing, and so on) are likely much more of a barrier.

../Leigh

-----------------------------------------------------------


=============================================================================
Article: 1133 of comp.lang.apl

Subject: Re: Demise of the non-ASCII character set
Summary: Good news or not?
Date: Thu, 26 Mar 92 15:48:26 GMT



Quote:
>There seems to be more good news.  My understanding is that now, the
>Unicode proposal and the 10646 proposals have been merged.

>Since so many major players are involved in the Unicode consortium, no
>vendor will be able to ignore Unicode (and ISO 10646).

I'm worried :-)  As I stated earlier, unless each vendor moves its
non-standard functions to new, unique symbols, the confusion will remain.


=============================================================================
Article: 1109 of comp.lang.apl

Subject: Re: APL slash bang (Repost)
Date: 24 Mar 92 05:14:54 GMT

     Dan LaLiberte writes:

Quote:
>   ....  (It could also use commonly accepted precedence for numeric and
> logical operators (only) and left-to-right evaluation order, but this is
> not as big an issue.)

     Au contraire, I think this comment reveals that Dan's ideas of what
constitutes a "big issue" in language design are seriously uninformed.

     First of all:  how do you have a precedence scheme that only applies to
SOME primitives?  (Dan calls them operators....)  Do the ones 'without'
precedence take higher or lower precedence than those that have it?  What is
'commonly accepted precedence' for min or max or inner product?

     Similarly, right-to-left evaluation facilitates a functional style of
programming without a LISP-like profusion of parentheses.  Functional idioms
are, IMHO, a major part of the learning curve from 'writing <name of common
procedural language> programs in APL' to 'thinking and writing in APL', and I
think that language encouragement for functional style helps minimize that
learning curve.

     I like J; it seems to me to correct the actual defects of APL.  Fixing
only the character set while retaining the syntactic anomalies seems to me too
little; introducing further syntactic anomalies or restructuring the basic
syntax does not seem like a 'fix' at all.

                                      Dave Gillett
=============================================================================
Article: 1139 of comp.lang.apl

Subject: Re: APL slash bang (Repost)
Summary: Precedence and order of evaluation
Date: Fri, 27 Mar 92 03:55:33 GMT


Quote:

>     First of all:  how do you have a precedence scheme that only applies to
>SOME primitives?  

>     Similarly, right-to-left evaluation facilitates a functional style of
>programming without a LISP-like profusion of parentheses.  

I am not convinced that _no_ precedence is the _only_ way to go.  What's wrong
with (1) plus/minus/or (2) times/divide/and (3) power (4) everything else,
in order of increasing precedence?  

Nial uses left-to-right evaluation in an intuitive way, functional without
becoming Lispy.  The "trick" is a syntactic device dot . equivalent to a left
parenthesis.

I'm not (necessarily) endorsing either of the above; just want to point out
there _are_ reasonable alternatives.  I agree with Dan LaLiberte that these
issues are less important than some others we have been discussing.


=============================================================================
Article: 1166 of comp.lang.apl

Subject:      Re: APL slash bang (Repost)
Date:         30 Mar 92 21:00:06 UT

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

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
languages*.

                                       Dave Gillett
=============================================================================
Article: 1196 of comp.lang.apl

Subject: APL, Q'Nial.  J questions
Summary: Is it worth my while to bother with J for data analysis ?
Keywords: APL.  Q'Nial.  J. data analysis. IBM 5100. Data General
Date: 6 Apr 92 16:48:49 GMT

Dear Folks,

I first learned to love APL on and IBM 5100, now over 10 years ago.

I next enjoyed the Data General APL on an MV10000 about 5 years ago.
This was the only exceptionally good thing about the Data General machine.

When we sold the MV10 to buy a Sun, we tried Q'Nial, from Queen's
University and Nial Systems ((155 Queen Street, Ninth Floor, Ottawa,
Ontario. (613) 234-4188).  Someone a couple of weeks ago said that
Q'Nial was very slow.  My experience was that once you were within
Q'Nial, it was fast enough, but that getting data into it was
painfully slow.  Even reading in data in Q'Nial's .ndf format was slow.
It takes over 45 minutes to read in a 600k data file.  I wrote some c
routines to speed the IO for one data format, but I'm not going to use
Q'Nial for any new projects unless they greatly improve the parser.

I generally like Q'Nial. I found its operator precedence rules
confusing; I prefer the work from the right approach of APL. We
originally got Q'Nial rather than APL because it was much cheaper than
the STSC APL for Suns.

[text re: J deleted]

With much interest,

Purvis.

=============================================================================
Article: 1206 of comp.lang.apl

Subject: Re: APL, Q'Nial.  J questions
Summary: Nial syntax
Date: Fri, 10 Apr 92 18:58:26 GMT

Just a few words on Nial (nee-AL).


Quote:
(bedenbaugh) writes:
>...  Someone a couple of weeks ago said that
>Q'Nial was very slow.  My experience was that once you were within
>Q'Nial, it was fast enough, but that getting data into it was
>painfully slow.  

That might have been me: "... the implementation of Nial was
not as refined (read: fast) as the theory..."

Quote:
>...  Even reading in data in Q'Nial's .ndf format was slow...

Nial is script based; perhaps not enough attention was paid to
the data interface and workspace support.

Quote:
>...  I generally like Q'Nial. I found its operator precedence rules
>confusing; I prefer the work from the right approach of APL...
>Purvis.


Always good to have user comments!  I was not part of the team that
designed and implemented Nial (Mike Jenkins, Jean Michel, Trenchard More
et al.), but was there when it happened ('84-85).  Trench taught a course,
then took me as his summer student at IBM Cambridge Mass. (to work on
details of "array theory").

The rationale of Nial syntax, I believe, is the following.  
Nial uses keywords (and includes if-then-else etc. control structures).
As a result, long expressions no longer fit on one line.  Rather than
having expressions evaluate right-to-left, hence _bottom-to-top_,
"normal" left-to-right order is introduced together with the Alonzo Church
"dot shorthand" for parentheses (lambda X.Y is lambda X (Y)).  For example,

    f g A i h B j . C k D is parsed as ((f (g A)) i (h B)) j (C k D)

where f g and h are monadic, i j and k are dyadic, A B C D are arrays.  
(The dot prevents C from becoming j's right argument.)  It was a
"design decision", obviously made with good intentions.  But users
have to decide whether or not it really works.  (Ambivalence is also
a notational shorthand in Nial: A op B is really op (A B) .)


=============================================================================
Article: 1125 of comp.lang.apl

Subject: Mastering J; Workspace; Ambivalence
Date: Thu, 26 Mar 92 06:18:44 GMT

OK I spent the last few hours looking at Donald McIntyre's APL'91 paper,
"Mastering J" :-)

I can understand people's enthusiasm.  Here are my thoughts...

Hook and fork are great.  I managed to translate the explicit form

looking at the answer.  With practice one can probably think directly in them.
(In another note I will try to compare the symbols of J, APL, and APL/!.)

[text re: J deleted]

My understanding is this: tacit forms are pre-parsed whereas explicit forms
are just strings to be parsed at run time.  Therefore, explicit forms (like
APL functions) are more conducive to debugging during program development
(i.e. if I modify a global subroutine g then an explicit form f that calls g
will use the new g, but a tacit form h defined from the old g will not).  
Tacit forms on the other hand encourage "script"-style programming, where
definitions (really assignments) are entered in a fixed order.  Of course the
two methodologies can be combined.  Now let's get back to dynamic versus
static scoping :-)  Exactly what does J allow in terms of local and non-local
variables inside explicit forms, and what is the syntax?  What about local
functions?

(As I posted earlier, dynamic scoping is very basic to the APL way of
programming.  It is used (1) for inter-procedural communication of complex
state changes, and (2) because the workspace has no concept of nearest
definition of local variables.)

My second reservation has to do with ambivalence :-)  I don't want to sound
obsessive--I think it has always been a mistake, but one I can certainly live
with, at least in plain APL.  I quote McIntyre:


     Remember that tacit functions are ambivalent.  You do not know how
     many arguments are to be used until you see the function used.  This
     one is written for dyadic use, so the rightmost verb is "append" and
     not "ravel".

Precisely the problem I had with many of the tacit forms in the paper.  Is
ambivalence worth the extra complexity of making fork/hook/with/atop functional
forms so much harder to decipher (and probably to write)?  If one had to
explicitly force expressions to be monadic (or dyadic) all the time, why
not nuke it from the start at the level of primitives?

If I misinterpret J, please correct me!  Comments will be appreciated.


=============================================================================
Article: 1126 of comp.lang.apl

Subject: Symbol Choices in J and APL/!
Date: Thu, 26 Mar 92 09:06:58 GMT

This article is meant to be mildly humorous :-) as I try to get inside
the head of Ken Iverson.

(1) brackets (left and right)

These are used in a tacit (functional) form to return the left and right
arguments respectively if the form is dyadic, or the sole argument
(right bracket) if the form is monadic.  The brackets are forcefully
communicative in this regard.  However, our eyes naturally hunt for
matching pairs of brackets, particularly the closing (right) bracket
when there is only an open (left) bracket.  The opposite case is much
easier to handle.  In fact ]var=.i.10 (quad gets var gets iota 10) can
be considered a descendent of APL's system commands )xxx.

(2) braces (find and amend)

Again the message here is visual.  The indexing expression  (<coords) { array
injects array elements into the accessor, whereas the assignment expression
values (<coords>) } array  goes the other way (it injects values into array
elements).  Braces look like arrows; I see them as heads (in profile)
talking to their neighbors.  (My choice for the comment symbol in APL/! is
o} :-)

(3) reverse and rotate

These use the same symbol |. and operate along the leading axis.  In a way
the original APL got it wrong, |-overstrike-o works along rows of a matrix
while minus-overstrike-o works along columns.  (In APL/! they are -. and +.
though originally I had |. and ~|. -- but decided quite independently of
Iverson that they are wrong.  Note -. for reverse is especially nice.)

(4) fork and hook and atop and with


to look like APL jot (small circle).  The symbol for with ("currying") is &
for obvious reasons.  It is interesting that fork and hook are achieved by
simple juxtaposition: (... h g f e d c b a) is (... h(g f(e d(c b a)))...)
where every (x y z) is a fork: (x left-argument) y (z right-argument) ; and
the possible leftover (u v) is a hook: right-argument u (v right-argument) .
(McIntyre's APL'91 paper only defined the dyadic fork and monadic hook,
I believe.  What are fork and hook in the general case under ambivalence?)
I am surprised that Iverson chose to use symbols for the conceptually simple
atop and with, instead of the more difficult fork and hook.  Any ideas?

(5) rho and iota and take and drop and replicate

These are among the most commonly used APL functions.  As building blocks
of idioms (together with operators), they are what APL is all about.  In J
they are represented by $ i. {. }. # respectively (I'm not sure about drop),
three different styles of symbol combinations.  In most screen fonts I have
seen, the $ is ugly and both $ and # are very dark and threatening.  In
the Courier font, the $ looks too much like S (the bar does not run through).
Not all fonts look alike (for example vertical placement of tilde ~), but
these primitives occur so often they really ought to look good (at least
not distracting).  How does one recognize an idiom when it contains so many
different styles of symbols?

(In APL/! they are given by / ! | ~| /. respectively, as has been described
earlier.  Common idioms are  ->COND/LABEL  ->CONDS/.LABELS  conditional goto's;
((A!A)=!/A)/.A  to remove duplicates; (-+/.^.\.-.' '=A)~|A  to remove trailing
blanks.  I am certainly willing to consider other possibilities; how about
? for rho?)

(6) grade and mesh

McIntyre's paper contains a fascinating note written by Ken Iverson on the
subject of the expand function, which isn't a primitive in J.  The upshot is
that grade-up /: and grade-down \: are used to define expand and also the
"mesh" function in Iverson's APL book:  \'sek',0 1 0 1 0,'ta'\  is  'steak' .
In J, (/:\:u) { (u#a),((-.u)#a)  returns  a (u is boolean vector).  Curious
that after all these years mesh \...\ ends up being defined in terms of
slashes--the ascending and descending grades.  (In APL/!, grade not-less-than
and grade not-greater-than are ~<. and ~>. respectively.)


=============================================================================
Article: 1159 of comp.lang.apl

Subject: Re: Symbol Choices in J and APL/!
Date: Mon, 30 Mar 92 03:16:46 GMT

Quote:
Bill Chang writes:
> This article is meant to be mildly humorous :-) as I try to get inside
> the head of Ken Iverson.

One might try reading what Iverson writes, for example the J dictionary.
The back cover presents the spelling scheme _in toto_, and Section II F
defines the monadic and dyadic meanings of hook and fork.

Quote:
> (1) brackets (left and right)

> These are used in a tacit (functional) form to return the left and right
> arguments respectively if the form is dyadic, or the sole argument
> (right bracket) if the form is monadic.  ...
>  ...  In fact ]var=.i.10 (quad gets var gets iota 10) can
> be considered a descendent of APL's system commands )xxx.

[ and ] are verbs and syntactically are treated no differently from other
verbs.  It does not seem fruitful to consider [ and ] as "quad gets ..."
or "a descendent of APL's system commands )xxx":  "System commands" are
syntactic anomalies whereas [ and ] are verbs; prefacing an expression with
[ or ] does not always produce the same effect as "quad gets".

Quote:
> (3) reverse and rotate

> These use the same symbol |. and operate along the leading axis.  In a way
> the original APL got it wrong, |-overstrike-o works along rows of a matrix
> while minus-overstrike-o works along columns.  (In APL/! they are -. and +.
> though originally I had |. and ~|. -- but decided quite independently of
> Iverson that they are wrong.  Note -. for reverse is especially nice.)

Like many primitives in J, |. is defined to work along the leading axis
and application to other axes can be obtained by using rank; for example,
|."1 reverses/rotates along the final axis.  Similar reasoning applies
to / and \ which serve the role of slash and slash-bar, and back-slash
and back-slash-bar.

Morover, + * - % are assigned meanings as follows.  Reverse/rotate seem
less apt than the current meanings:
                                .                          :
+  conjugate . plus      real/imag . gcd (or)       double . not or
*  signum . times        polar . lcm (and)          square . not and
-  negate . minus        not . less                 halve . match
%  reciprocal . divide   matrix inv . matrix div    square root . root

In a separate article, Bill Chang writes:

Quote:
> Is it possible to redefine J's symbols, without hacking the source?

Primitive symbols can not be redefined without changing the source.

p.s.  Insults affixed with :-) are no less insulting for that.

------------------------------------
Roger Hui, Iverson Software Inc., 33 Major Street, Toronto, Ontario  M5S 2K9
Phone: (416) 925 6096;  Fax: (416) 488 7559
=============================================================================
Article: 1165 of comp.lang.apl

Subject: APL?! (ASCII rendition of ISO APL)
Date: Tue, 31 Mar 92 00:17:40 GMT

APL?!                                                 DRAFT 30 March 1992

A quick summary.  The most commonly used APL operations are given symbols.
There are few symbol combinations.  Keywords are named after functions
instead of glyphs because glyph names are more verbose and less standard.
Ambivalent APL symbols are given the dyadic function name, because it is
not always possible to distinguish (automatically) between monadic and
dyadic use--better to stick to the dyadic name uniformly.  Luckily, the
less intuitive times-sign, modulo-magnitude have symbols instead of keywords.
As for user names conflicting with keywords, I suggest using the opposite
case for keywords.

? rho [looks a bit like rho; query an array for its shape]
! iota [upside-down i; factorial is product of 1 2 3 ... n]
^ take [head; looks like up-arrow]
~ drop [tail; array less head]
# execute [convert to number]
$ format [convert to string]
= < > ~= <= >= comparisons
+ - * % | arithmetic (plus minus times divide modulo)
/ reduce and compress; \ scan and expand
/[!1] \[!1] along leading axis [/-minus and \-minus are unnecessary]
.f. outer-product
f.g inner-product

not and or nand nor power log [keywords]
rotate [reverse is rotate by 180 degrees]
rotate[!1] along leading axis [circle-minus is unnecessary]
transpose member up down encode decode choose solve deal circle [keywords]

-> goto; <- gets [so A< -B must be written with a space]

_number (negative constant); "name (glyph name for I/O purposes)

I hope this is a relatively straight forward solution, to the problem
of transliterating (most of) ISO APL.  Whether or not anyone will use
it is another matter.  Although I personally think APL/! is more
consistent and economical in terms of design, I do not necessarily
prefer it.  In any case, I got no converts :-)

I would like to thank everyone who has contributed to the discussion.
Further suggestions are also welcome!


p.s. How does one pronounce ?!
=============================================================================
Article: 1172 of comp.lang.apl

Subject: Re: APL?! (ASCII rendition of ISO APL)
Summary: Addendum
Date: Tue, 31 Mar 92 13:15:03 GMT


Quote:
(Bill Chang) writes:
>APL?!                                                 DRAFT 30 March 1992

I left out min and max (keywords).  Also, < = must be written with a
space if = is the (left) argument of an operator (ditto for > =, ~ =).


=============================================================================



Mon, 18 Dec 1995 04:07:59 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. Arriving Soon in APL Quote Quad

2. Now in December in APL Quote Quad

3. Coming in December in APL Quote Quad

4. APL Quote-Quad

5. Coming in June in APL Quote Quad

6. Call for Participation: APL Quote-Quad

7. APL quote-quad

8. APL Quote Quad

9. Changing management at APL Quote-Quad

10. APL Quote Quad, Vectors and others

11. APL Quote Quad

12. Coming in March in APL Quote Quad

 

 
Powered by phpBB® Forum Software