Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!watserv1!70530.1226@compuserve.com
From: Mike Kent <70530.1226@CompuServe.COM>
Subject: What _I_ would like to see
Message-ID: <930411074536_70530.1226_CHV24-2@CompuServe.COM>
Originator: daemon@watserv1.uwaterloo.ca
Sender: news@watserv1.uwaterloo.ca
Organization: University of Waterloo
Date: Sun, 11 Apr 1993 07:45:36 GMT

In article seary@sfu.ca (A.), writes:

>> ... I'd like to start a thread ...  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

(c) is a point well taken, but will never happen:  We Are Serious Here.

(a) should be entertained, IMO,  only with the understanding that vendors
will _not_ rush out to implement such suggestions.  There are two reasons
for this curmudgeonly attitude about progress.  One is point (b) in the
same list; the War of the Enclosures (Boxers vs. Nesters) soaked up so
much of the APL community's energy (without ever being settled) that I am
reluctant to foment any more such fratricide.  The other reason is a
suspicion that it will lead to an ever-more-elaborate language without
addressing the real problems of programming large-scale systems. 

Somebody (maybe it was Niklaus Wirth, but that's just a guess) long ago
described APL as "tomorrow's language for yesterday's problems"; even
elegant hacks on the APL theme (like J, and A) can still wear that shoe
comfortably.  What _I_ would like to see added to APL is facilities which
allow me to deal comfortably with systems which require 50 or 100
thousand lines of generalized-array APL code to implement.  Comfortably
here means that one person can dig into such a system and make changes to
it without fear of breaking all the stuff which works now.  Modern control
structures would help, more primitives (or more behavior from existing
primitives) will not.  [N.B. APL2 defined operators are an example of
something which is a help in this regard; see Ed Eusebi's APL 85 paper, 
"Operators for Program Control".  I wrote a paper for QQ a couple of
years back on using operators to generate character-stream filters, where
the point was that the only tricky part of the job is geting the control
flow right, and it's the same for a wide class of filters.  Sad to say,
only IBM provides defined operators, and I use Manugistics' products at
work.  The current version of []NA in mainframe APL2, with its provision
for interface-description files, and the ability to name-associate across
separate APL name scopes is another Good Thing.]

While we have been asking for enhanced squish and inverse-quash, the rest
of the world has been groping towards convenient, effective encapsulation
and re-use techniques.  We don't even have the kind of reasonably-useful
utility libraries that the average C programmer takes for granted, much
less something like the fundamental classes that come with a typical
good-quality C++ compiler.

The good news is that APL is really a better _language_ than C, Pascal,
or whatever, and that adding structuring and encapsulation facilities can
be done without a deadly impact on the syntax, much as Common LISP
absorbed CLOS without disturbing the lambda-calculus core.  If the major
vendors could come to some agreement on what to do (which probably means
if the Standards process starts to get somewhat prescriptive rather than
_only_ descriptive), I'd be pretty happy.  I'd even be pretty happy if
the major vendors could come up with a decent list of library routines
and agree on the function names and the interfaces to them, so that I
could write code which doesn't care if it's []NREAD or AP 210 that's
handling host files, for instance.  (I know that most of us here have our
own versions of these kinds of things, but the chance that I can bring
_my_ toolkit to bear on _your_ modestly large system written three years
ago and now needing some significant extensions, without introducing a
lot of redundancy and maybe even some incompatibility, and without having
to write interface-to-the-interface bridge code, is vanishingly small.) 
There was some noise about this being some sort of project at APL 92, but
there does not seem to have been any further effect.

I guess my basic point is that movement isn't necessarily progress;
progress has to be evaluated relative to the goal you are trying to
reach, and I don't see any very clear large objectives in a lot of the
proposals for APL tweaking that float around, sometimes here, or in the
literature, or at the annual get-togethers.  

// Mike Kent        70530.1226@CompuServe.COM


