Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!ux1.cso.uiuc.edu!uicsrd.csrd.uiuc.edu!jaxon
From: jaxon@uicsrd.csrd.uiuc.edu
Newsgroups: comp.lang.apl
Subject: Re: composition of APL expressions
Message-ID: <49700012@uicsrd.csrd.uiuc.edu>
Date: 31 Aug 89 21:03:00 GMT
References: <215026@<1989Aug26>
Lines: 43
Nf-ID: #R:<1989Aug26:215026:uicsrd.csrd.uiuc.edu:49700012:000:2086
Nf-From: uicsrd.csrd.uiuc.edu!jaxon    Aug 31 16:03:00 1989


Before 1973 several APLs used left-to-right order of EVALUATION.  But so
far as I know every APL has always defined functions as right associative
with equal precedence (would anything else still be APL?)  

From your comments I believe it is the right associativity that causes you
the most problems.   This was adopted from conventional mathematical usage,
where the function name appears to the left of its arguments  f(x,y) and
compositions occur right to left  f(g(x)) == (fg)(x).  The primitive functions
are pretty well adapted to this syntax.  If you choose user-function names
carefully and arrange their arguments with an eye toward function usage
you can avoid most parenthetic messes.

Most line editors have a recall of the last line, on APLB we made ATTN 
(aka BREAK) do that when it is the first keystroke of a new input.  So a
built-up expression might grow like:
      A+B
42                (hit ATTN at next prompt to see:)
      A+B
     ,R<-         (insertion editing comand)
      R<-A+B      (echoed for confirmation, you type RETURN)


Mathematica has an intriguing pair of built-in vectors IN[] and OUT[] which
are the history of inputs and outputs in this session (the names are read-only)
The last element of OUT[] is abbreviated as %% or something like that.  Now,
in Mathematica inputs and outputs are the same type (expression) so IN[17]
and OUT[17] are call-by-name and call-by-value versions of your 17th entry.

A lot of workstations, terminals and PCs have local editing features that
subsume all of the line-editing and input history.  I think the language
should stay clear of history substitutions (ala csh).  But I'd love to
preserve the output arrays in a nested vector somewhere, if only I could
convince enough users to devote the memory & disk space to doing this. 

I always forget to say "R<-" before "BIG_EXPENSIVE_FUNCTION_CALL".  I guess
just preserving the last computed result would be enough for me.  APL2 has
something called Quad-R that might do this already... any IBMers know?

regards  greg jaxon  (jaxon@uicsrd.uiuc.edu)