Newsgroups: comp.lang.apl
Path: watmath!watserv1!utgpu!cs.utexas.edu!sdd.hp.com!think.com!ames!haven.umd.edu!socrates!socrates!rockwell
From: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Subject: Re: Expressiveness of Language
In-Reply-To: wchang@cshl.org's message of Mon, 23 Mar 92 20:38:52 GMT
Message-ID: <ROCKWELL.92Mar23231554@socrates.umd.edu>
Sender: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Organization: Traveller
References: <1992Mar20.184205.4943@watmath.waterloo.edu>
	<LIBERTE.92Mar20173238@birch.cs.uiuc.edu>
	<ROCKWELL.92Mar21003041@socrates.umd.edu>
	<1992Mar23.203852.4998@cshl.org>
Date: Tue, 24 Mar 1992 04:15:54 GMT
Lines: 97

I wrote:
   >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

Bill Chang:
   Are you suggesting that we abandon J's default symbol combinations
   and use named functions instead, as a rule? :-)

Huh?  I'm not sure I understand.

In the above, I was using 'fn' to stand for an arbitrary function.
Whether it is a named function or an anonymous function does not
affect the way things work.  If you use the above notation, in J, you
will get a function which is not ambivalent.

Yes, you could assign either of functions a name:
monad_fn =.  fn : ''
dyad_fn  =.  '' : fn

And, in general, assigning names is an effective way of commenting
your code.

   Whose list should we use?  How do we arrive at a standard, so we
   can all talk coherently?  If you have such a list and can help
   APLers learn J, please post it!

I have, in the past, attempted to summarize the definitions of each
and every J symbol I used.  When there are questions, I attempt to
answer them as best as I am able.

When there are no questions, I can only assume that those people who
are interested understood things to their satisfaction.

   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.

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
