Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!watserv1!seary@sfu.ca
From: seary@sfu.ca
Subject: Things We'd Like to See
Message-ID: <9304102154.AA03070@monashee.sfu.ca>
Originator: daemon@watserv1.uwaterloo.ca
Sender: news@watserv1.uwaterloo.ca
Organization: University of Waterloo
Date: Sat, 10 Apr 1993 21:54:18 GMT
X-Mailer: ELM [version 2.3 PL11]

To generate more APL-related discussion in this forum, I'd like to start a
thread called "Things We'd Like to See" (after the old Mad comic feature).
It should contain:
  a) suggestions to significantly enhance APL
  b) suggestions that encourage convergence of the various flavours of APL
     (this might be even more important)
  c) humour
To start things out, I have two Things:
I) Dyadic execute.
   I will follow I-APL and use "h" to represent FORMAT (for "h"ollerith?)
   Also "y" will represent execute ("y" not? Also it's a kind of upside-down h)
   Both IBM's APL2 and Sharp APL allow character left arguments to dyadic
   format, and both follow the same rules (yay!)(Except Sharp's
   version also allows empty left arguments to act like monadic
   format, which can be very handy. How about it IBM? Dyalog? Manugistics?)
   The left argument can include embedded cr/lf or end-of-line characters,
   allowing direct translation into ASCII files.
   The suggestion: Make dyadic execute a true inverse of dyadic format.
   Thus:   1 2<->T y (T<-'55.55 ',#TC[2 3],'55.55 ') h 1 2
   There is at least one HUGE advantage to this (aside from symmetry):
   dyadic execute can read multi-line files, ignoring extraneous characters
   (like cr/lf) or skipping over non-numeric data which is sometimes buried
   in a file and otherwise tricky to handle. Also, there is no need for:
   M<-disclose y"c[2] sstomat D~#TC[2 3] NB. sstomat<-> segmented
                                         NB. string to matrix
   which is slow and large (in terms of temps). This would not only be upward
   compatible with ALL current APL systems, it would be compatible
   with all those ASCII data files out there (and there are a lot more
   of those.) It even gives APL the power of the FORTRAN FORMAT statement!
II) Extending o:
   In the article "The story of o", E.E.McDonnell describes a certain late-
   night session in extensions of dyadic o to the complex domain.
   18 o A returns the representation of A in Roman numerals
   _XVIII o A is, of course, the inverse. (it was pretty late, he says)
   Hmmm. Why not 'BESSEL' o A, 'LNGAMMA' o A,...? Or is this stepping into
   #NA territory? (I only have mere APL2/PC)(I can't believe I'm complaining).
III) (No one expects the Spanish Inquisition)
   Dyadic #FX allows one to "fix" certain properties of user-defined
   functions (in IBM's APL2. Only Sharp has something similar, alas).
   There are currently 4 flags to set. I'd like to add one more:
   A flag to mark the (dyadic) function as commutative (or don't care
   whether it is or not). There is already special code for 
   for reductions and scans of +, x, |_, etc...This would
   allow scan to treat the function as it does + , x, ^, and other commutative
   functions, instead of recalculating all the sub-scans as it currently
   does for ALL user defined functions. For one thing, generating fractals
   would become not only trivial to program, but also efficient. One could
   also write cover functions to make +.x\ (etc.) more efficient.

   I'll leave it to the readers to find the correspondence between I),
 II), III) and a), b), c).
                            A.

