[comp.lang.apl] composition of APL expressions

neitzel@tubsibr.uucp (Martin Neitzel) (08/27/89)

I view most expressions as transformations of the right-most argument,
and composing those transformations in reverse order always felt
quite cumbersome to me.

* Has any experience been made regarding APL with a left-to-right
  evaluation?  I guess there must have been some investigations in
  this matter.  Any references?

* How are current APL systems supporting the "editing" of an APL
  expression?  All the systems I have seen only provide a conventional
  line or full screen editor.  Beyond that, none of them was
  specifically tailored to edit and modify APL expressions.  All
  systems were heavily based on cursor movements.  I could image some
  simple history mechanism (see csh(1)) adapted to APL to be
  worthwhile (something like "3 4 \shape !-2").

* Beyond editing, what are systems doing to aid both the composition
  and analysis of expressions?  For example, is there a system that
  tracks the values and shapes of all subexpressions while the whole
  expression is tweaked by the programmer/user at the same time?

							Martin

jaxon@uicsrd.csrd.uiuc.edu (09/01/89)

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)


      

f31915s@taltta.hut.fi (Juha Haataja) (09/11/89)

In article <49700012@uicsrd.csrd.uiuc.edu> jaxon@uicsrd.csrd.uiuc.edu writes:
>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)


Quad-R (and Quad-L) in APL2 contains right (and left) argument of the 
current function in case of interrupt or error. This is very convenient
when debugging programs: it is possible to list the arguments and also
to respecify them and try to resume execution. So, the answer to your
question is no - Quad-R (and Quad-L) is set only when an error or
interrupt occurs in a primitive function, so it can't be used to
query the last computed result.

But it sure would be nice to be able to recall that last result!


__________________________________________________________________________
| Juha Haataja                                  | lk-joh@finhut.bitnet   |
| Helsinki Univ. of Technology Computing Centre | jhaataja@sorvi.hut.fi  |
| Otakaari 1, 02150 Espoo, Finland              | voice: +358 0 451 4325 |