                                   Chapter 10

                            USING J : PROGRAMMING IN J


      Programming in J


*========================================
# Programming in J

+------------------
| Mark Keil
| <1991Nov5.212542.20160@apollo.hp.com>

I have gottem my copy of Programming in J .
Thank you ISI , you folks are fast at returning orders.

In chapter 1, section B there is the sentence:
 "Do not attempt to read it [the dictionary -keil]
  as an introduction to the language; to do so might
  prove as frustrating as reading a full French dictionary
  to learn french"

I agree with this statement. The catch [22] of this is that
one has to buy the book [Prog in J] to find this out. As far
as I can remember this isn't stated in the catalog or in the
dictionary... So for the rest od you who havn't gotten
Programming in J yet, I recommend that you get it.

Even so, I still feel that I'm missing something. I just can't
put my finger on it. Maybe it's the terseness of the language
description, or maybe it's the labels of nouns/verbs/pronouns/etc
that are throwing me. Maybe it is assumed knowledge that I don't have.
I have done a number of the examples, and they work, and give me
insite into their operation, but I feel that I am missing the big
picture somehow. I suspect that there is an unexclaimed substructure
to the language that, if I could see it, would make it all(?) clear.

I suspect that hearing the "WHY" for many aspects of the language,
would also help me to understand.

I would appreciate any enlightenment that you other J folks could give me.

Thanks,


+------------------
| Joseph. W. Davison
| <1991Nov5.234044.3676@cbnewsc.cb.att.com>

In article <1991Nov5.212542.20160@apollo.hp.com> keil@apollo.hp.com (Mark Keil)
 writes:
..
>Even so, I still feel that I'm missing something. I just can't
>put my finger on it. Maybe it's the terseness of the language
>description, or maybe it's the labels of nouns/verbs/pronouns/etc
>that are throwing me. Maybe it is assumed knowledge that I don't have.
>I have done a number of the examples, and they work, and give me
>insite into their operation, but I feel that I am missing the big
>picture somehow. I suspect that there is an unexclaimed substructure
>to the language that, if I could see it, would make it all(?) clear.
>
>I suspect that hearing the "WHY" for many aspects of the language,
>would also help me to understand.
>
>I would appreciate any enlightenment that you other J folks could give me.
>
>Thanks, Mark
>

Well, this won't be too enlightening, but it may prompt a reply that
will be.

I share these feelings.  I was a novice APLer for a while, and was impressed,
but found the need for the special characters a hindrance.  I was therefore
pleased to stumble across J in this newsgroup, quite by accident.  I
picked up a mac version and have attempted to learn it, but haven't yet
gotten the book.  One of the difficulties I encountered was the
differences from APL, and mail about "hook" and "fork" and other
amazing but obscure references.  Searching about, I found an article in
Vector (by Iverson?) that talked about J.  Unfortunately, I don't have
the information handy, so I can't give you a good pointer, but I think
it was March '90 or '91.  Anyway, it was helpful in pointing out why it
differs from APL and some of what the goal of the work is.  Perhaps
some of the J cogniscenti would provide a better reference, or even
make a copy available via FTP.

And now, for something completely different:

I find getting a toe-hold on the language very difficult -- climbing a
glass mountain.  The tutorial on my mac isn't too helpful because
when I try the tutorial it doesn't act the way I expect, and I usually
can't guess what the magic incantations are going to do before they're
gone.  With no english description of what I'm seeing, I see a line of
magic (the incantation) followed by a bunch of numbers:

a $%&.:##@! b

1 2  3
    - - -
6 4 ] 7 ]
    - - -


Huh?  Where's the bun?

If I'd not played with APL before, I'd have absolutely no idea what was
going on!  And my APL (STSC APL*PLUS on an XT-clone) didn't have boxed
arrays, I don't think, so it took awhile to figure out what they were.

It looks fascinating and really powerful, but I don't know if I want to
drop some of my gold and take the spell book  -- maybe my character is
geared to strength and agility, not to intelligence and dexterity.  Who
knows, the book might even be cursed!  ( "The book is stuck to your
hand, you are unable to put it down." or worse: "Your mind is filled
with wondrous visions, pushing out all else -- you no longer recognize
your spouse and children!")


+------------------
| Peter S. Shenkin
| <1991Nov6.035148.8485@ctr.columbia.edu>

In article <1991Nov5.234044.3676@cbnewsc.cb.att.com> jwd@cbnewsc.cb.att.com
 (joseph.w.davison) writes:
>In article <1991Nov5.212542.20160@apollo.hp.com> keil@apollo.hp.com (Mark Keil)
 writes:
>...
>>Even so, I still feel that I'm missing something...
>>...I feel that I am missing the big
>>picture somehow.
>
>I share these feelings...
>..One of the difficulties I encountered was the
>differences from APL, and mail about "hook" and "fork" and other
>amazing but obscure references....

Yes, I agree. We need a book with a title like, "J for APL Users," showing
how familiar APL idioms translate into J, when they do, and what the
appropriate J idioms are, when they don't.


+------------------
| Raul Deluth Miller-Rockwell
| <ROCKWELL.91Nov6005949@socrates.umd.edu>

Mark Keil:
   >Even so, I still feel that I'm missing something. I just can't put
   >my finger on it. Maybe it's the terseness of the language
   >description, or maybe it's the labels of nouns/verbs/pronouns/etc
   >that are throwing me. Maybe it is assumed knowledge that I don't
   >have.  I have done a number of the examples, and they work, and
   >give me insite into their operation, but I feel that I am missing
   >the big picture somehow. I suspect that there is an unexclaimed
   >substructure to the language that, if I could see it, would make
   >it all(?) clear.

Bringing us to the age-old question "how much elegance can dance on
the head of a pin"?

Whenever I try coming up with a "complete description" of some J
feature, I usually find myself going over a lot of detail about how J
is different from some other language.   So I guess that means I
should write some stuff along the lines of "J form a ______
Programmer's Point of View"??

For example, I read in a magazine today about Fermant's Little
Theorem, and wasn't sure if I was getting the point, so I wrote a
little code to test it out for a variety of test cases.  First, I
tried some APL code:
    _
    V R <- A FLT P
[1] _ R <- P|_1+A*P-1
    V

Playing around with that a little, I find that if P is a prime, and if
A is prime with respect to P, that R is zero.  Playing around with
that a little more, I find that maybe that's not true after all:

   T o.FLT T <- 2 3 5 7 11 13 17 19 23 29
1 0 0 0  0  0  0  0  0  0
0 2 0 0  0  0  0  0  0  0
0 0 4 0  0  0  0  0  0 14
0 0 0 6  0  0  0  0  7 17
0 0 0 0 10  0  0  1 10  4
0 0 0 0  0 12  1  3 18 13
0 0 0 0  0  0  7  6 19  2
0 0 0 0  0  0 11  4 22 11
0 0 0 0  0  0  6  7 20 18
0 0 0 0  0 10 13 15  2  8

[Actually, before I did the above, I tried it with a slightly longer
list of primes, and got hit by a "domain error".]  Now, that looks
like roundoff error, so I thought I'd try it in J -- just to get a
feel for how J deals with this sort of thing.

flt =. '' : '  y. | _1 + x. ^ y. - 1 '  " 0

   t flt/ t =. 2 3 5 11 13 17 19 23 29
1 0 0 0  0 0 0 0 0 0
0 2 0 0  0 0 0 0 0 0
0 0 4 0  0 0 0 0 0 0
0 0 0 6  0 0 0 0 0 0
0 0 0 0 10 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0

Ok, so first off it's obvious that J doesn't support arbitrarily large
integers.  At least not yet.  Second off, it looks like J does a
pretty good job of avoiding roundoff error, at the expense of a little
precision.  [I'd expect that diagonal to be primes minus 1:  1 2 4 10
12 16 18 22 28 ..., and it looks like the 12 was sacrificed to detect
floating point errors -- though this might be an artifact of different
floating point architectures on the two machines I was using.]

So I think this exemplifies one of the "design decisions of J" --
accuracy over precision.  [But if I'd skipped this entire digression,
except for the preceeding sentence, what would you have thought?]

   >I suspect that hearing the "WHY" for many aspects of the language,
   >would also help me to understand.

Well, I suspect that if you could frame a more specific question it
would be easier to answer :-)  I suppose the problem is that there's
almost no limit on what can be said about J...

Joseph W. Davison:
   And now, for something completely different:

   I find getting a toe-hold on the language very difficult --
   climbing a glass mountain.  The tutorial on my mac isn't too
   helpful because when I try the tutorial it doesn't act the way I
   expect, and I usually can't guess what the magic incantations are
   going to do before they're gone.

Maybe print the thing out?  [Paper is at least semi-permanent.]

   With no english description of what I'm seeing, I see a line of
   magic (the incantation) followed by a bunch of numbers:

   a $%&.:##@! b

Mentally parsing that:
#@!  takes the factorial then counts how many results you got.  Kinda a
   waste of time, since # would do...
#@! b  is however many things there are in b
%&.:#  looks like a syntax error.. oh well.  ('&.' wants a left and
   right argument, as does ':', but there's nothing between the two).
   I may be wrong about this, with the new idiomatic forms, but I'd
   have to try it out to be sure.

   1 2  3
       - - -
   6 4 ] 7 ]
       - - -

Um... I wouldn't expect any sort of box around just one element,
unless some fancy formatting were being done.  Also, I don't see much
of a pattern in that sequence (now, if it were 1 2 3 4 5 6, that would
be different).

As a hint, though, if you can extract part of an expression, and
evaluate it, you'll get a much better idea of what's going on.  For
example:
  #@! 1 2 3 4 5 6
which I think has the result:
1 1 1 1 1 1

[[NB. sws.  I get
6
]]

You could try:
    ! 1 2 3 4 5 6
and get
1 2 6 24 120 720
which seems to say that '!' gives factorials

You could try:
   <@! 1 2 3 4 5 6
and get
+-+-+-+--+---+---+
|1|2|6|24|120|720|
+-+-+-+--+---+---+

[[NB. sws.  Well...
+----------------+
|1 2 6 24 120 720|
+----------------+
]]

which seems to say that '!' is applied independently to each number.
['<' is a handy little thing for figuring out what the arguments would
be to a function.]

You could try
   # 1 2 3 4 5 6
which yields
6
or, you could try
   # 1
which yields
1

And, since '#' counts the number of items to which it is applied, you
might decide that '#@!' returns a 1 for each number in its argument.
[And you'd be right.]

[[NB.  sws.  Well I think it just counts the items in it's argument]]

One last thing you might try is
   #@!
which yields
+-+-+-+
|#|@|!|
+-+-+-+
And this tells you that there is nothing much hidden about the way
that function is parsed...

   Huh?  Where's the bun?

Yeah, well....

Anyways, nothing ventured, nothing gained.


+------------------
| David Feustel
| <1991Nov06.124604.25191feustel@netcom.COM>

What I still haven't comprehended is what J's control structures are.
At present I see the language as a very effective tool for generating
arrays, matrices and vectors with a few keystrokes. I cannot see this
language being used for serious programming.


+------------------
| Mark Keil
| <1991Nov6.200732.6424@apollo.hp.com>

In article <1991Nov06.124604.25191feustel@netcom.COM> feustel@netcom.COM (David
 Feustel) writes:
> What I still haven't comprehended is what J's control structures are.

It's NOT as easy as for/while/until cause it's way different.
 (this much I can figure out)

When structured programming came into vogue, it took a while to change ones
view of how to structure a routine. With no goto's one had to thing of a new
organization of ones routines.

Well, with J, it appears that yet another (re)organization is required.
It would seem that each loop or "statement" of a then/else clause needs to be
defined prior to it point of use as a single token.
I think that this is a side [main?] effect of J being a functional language...

Section 1-M of "Programming in J" deals (sort of) with control structures.
The section is called "EXPLICIT DEFINATION OF VERBS", and the first half
of the section talks about how to explictly define functions. (Of course
they don't use the word functions, you have to figure this out) The second
half of the section mentions looping & direct control & recursive definition
as "three schemes commonly used in explicit definition". Then you get to look
at the examples provided to figure it all out. The difficulty I have is that
it is never clearly stated: "To do what would be looping condtructs in other
languages, use the following construct"

The biggest problem that I have with J, is in the documentation. There just
doesn't seem be a bridge to help users of other languages adapt to
this new  style. Much language documantion has too much verbiage, and
not enough examples and  exercises. J documentation seems to be all
examples and no verbiage.

I liken trying to figure out J, to shooting X-rays through crystals to figure
out what the internal structure is like.

I would like to see sentences like: "Explicit definition of Verbs is a
more  general and powerful implementation of the concept of function
definition. Be careful  that you don't equate function definition with
Explicit definition of Verbs because  this could limit your ability to
conceptualize Explicit definition." [Raul & Roger, is the above
summary correct?]

What do other people feel about the documentation style and content?


+------------------
| Sam Sirlin
| <1991Nov7.012712.20790@csi.jpl.nasa.gov>


In article <1991Nov5.234044.3676@cbnewsc.cb.att.com>, jwd@cbnewsc.cb.att.com
 (joseph.w.davison) writes:

..
]> gone.  With no english description of what I'm seeing, I see a line of
]> magic (the incantation) followed by a bunch of numbers:
]>
]> If I'd not played with APL before, I'd have absolutely no idea what was
]> going on!  And my APL (STSC APL*PLUS on an XT-clone) didn't have boxed
]> arrays, I don't think, so it took awhile to figure out what they were.

I'd guess the comparison to majic is a complement, according to
Clarke's famous quote - J must be advanced technology!

One can do fairly simple things fairly easily in J, for
example simple sums, inversions, building simple 3vector manipulation
functions etc. Translating APL routines can be a pain (lots of
transpose type things), but not really too hard. Like APL itself,
there is alot of the language to know, but you don't need to know it
all to do many useful things.

With the minimum of printing out the status and the tutorial (input
and output togther) one can figure out some things, but writing a
multi-line branching function is hard without the dictionary. The
dictionary also doesn't take too much gold.

You might try looking at old articles in this group as well (I have
some). Are they archived anywhere?



+------------------
| Roger Hui
| <1991Nov7.054517.18980@yrloc.ipsa.reuter.COM>

Mark Keil writes:

> In cahpter 1, section B there is the sentence:
>  "Do not attempt to read it [the dictionary -keil]
>   as an introduction to the language; to do so might
>   prove as frustrating as reading a full French dictionary
>   to learn french"
>
> I agree with this statement. The catch [22] of this is that
> one has to buy the book [Prog in J] to find this out. As far
> as I can remember this isn't stated in the catalog or in the
> dictionary... So for the rest od you who havn't gotten
> Programming in J yet, I recommend that you get it.

There is no Catch-22.  The opening sentence of the third paragraph
in the dictionary says:  "A dictionary should not be read as an
introduction to a language, but should rather be consulted with other
materials such as Appendix B and References 4-5".  Appendix B are
the tutorial frames; reference 4 is "Programming in J"; and reference
5 is "Tangible Math".

Learning J from the dictionary proper could be a challenge.  However,
almost half of the dictionary booklet consists of tutorial frames,
and it is possible to get a good feeling for the language by
studying these tutorial frames (and the material in "Tangible Math").
In other words, the material sent to registered users does make
possible a start on using the language.

> Even so, I still feel that I'm missing something. I just can't
> put my finger on it.  ...
>
> I suspect that hearing the "WHY" for many aspects of the language,
> would also help me to understand.

On the "why" of APL and J, the dictionary points the reader to references
1-3 (last sentence, second paragraph).  If you are interested in such issues
it may be worthwhile to follow up on these references.  References 1-3 are:

1. Falkoff, A.D., and K.E. Iverson, The Design of APL,
IBM Journal of Research and Development, 1973 7; and The
Evolution of APL, ACM SIGPLAN Notices, 1978 8.

2. Hui, R.K.W., K.E. Iverson, E.E. McDonnell, and A.T. Whitney,
APL\?, APL 90 Conference Proceedings, APL Quote-Quad, Volume 20,
Number 4, 1990 8.

3. Iverson, K.E., A Dictionary of APL, ACM APL Quote-Quad,
Volume 18, Number 1, 1987 7.


+------------------
| Roger Hui
| <1991Nov9.042909.8290@yrloc.ipsa.reuter.COM>

Re comments from Joseph W. Davison.

It seems unreasonable to complain about " "hook" and "fork" and other
amazing but obscure references" on the one hand, and to decline to
obtain the available documentation on the other.  Regarding the fears
about the documentation.  Yes, there are definite dangers:  one might
actually learn something, and invincible ignorance will cease to be
available as a defense.


+------------------
| Roger Hui
| <1991Nov9.043727.8399@yrloc.ipsa.reuter.COM>

David Feustel writes:

> What I still haven't comprehended is what J's control structures are.
> At present I see the language as a very effective tool for generating
> arrays, matrices and vectors with a few keystrokes. I cannot see this
> language being used for serious programming.

Hmm, what is serious programming, if it is not "generating arrays,
matrices, and vectors"?  Moreover, it seems rather abrupt
to pronounce the language unsuitable for serious programming,
without comprehension of what the "control structures" are.

The following are a few examples of "control structures".
(u and v are verbs; m and n are nouns.)

u/
For example, +/ is summation and */ is product.  These are DO loops
in C or Fortran, commonly written for arrays of particular ranks
(whereas +/ works on arrays of any rank).

u\ and u\.
For example, +/\ are sums of prefixes and +/\. are sums of suffixes.
These are DO loops in C or Fortran.

u/.
The monad applies u to the oblique lines of the argument; the dyad
x u/. y applies u to items of y having the same keys as specified by x.
These are DO loops in C or Fortran.

u"n
Apply u to the rank n subarrays of the argument.  For example, +/"1
sums the lists in the argument.  This is a DO loop in C or Fortran.

u^:n
Apply u to the argument n times.  (u^:_ is the limit of the application
of u.)  This is a DO loop in C or Fortran.

u&v and u@v
Compose u and v.  These are the {} and s0;s1;s2; constructs in C.

u0`u1`u2` ... `un @. v
Apply one of the verbs u to the argument(s), according to the index
computed by applying v to the argument(s).  For example,
   fac =. 1:`(* fac@<:) @. *
defines the factorial function.  This is the if-then-else and
switch-case constructs in C.

m u n
Applies u to m and n, for arrays m and n of any rank.  For example,
m+n adds m to n for conformable arrays m and n, whether m and n
have one element or one million elements.  These are DO loops in C
or Fortran.

.. and many more.  Moreover, these facilities can be composed in
well-defined and consistent ways (as in +/\, +/\., and +/"n).

What are the control structures in J?  Answer: Everything.


+------------------
| Roger Hui
| <1991Nov9.044006.8504@yrloc.ipsa.reuter.COM>

Mark Keil writes:

> I would like to see sentences like: "Explicit definition of Verbs is a more
 general
> and powerful implementation of the concept of function definition. Be careful
 that
> you don't equate function definition with Explicit definition of Verbs because
 this
> could limit your ability to conceptualize Explicit definition."
> [Raul & Roger, is the above summary correct?]

I would not characterize function or verb definition this way.  In my
own work, explicit definition is hardly ever used; most defns are tacit.
See the paper by McDonnell, Iverson, and myself in the APL 91 conference
proceedings.  The paper has numerous examples of tacit defn, including
tacit defns in J of APL functions from the FinnAPL Idiom Library.
The article on "Tree Representation" I posted to this group on
1991 9 27 also illustrates this style.


+------------------
| Gillett, David
| <1991Nov9.001252.6288@yrloc.ipsa.reuter.COM>

     Mark Keil pleads for material that would explain J in terms of "how you do
things in other languages".  I have some mixed feelings about this.

     First of all:  Functional programming is not something new that J
introduced to the world.  I believe Backus' paper on it dates from 1962 -- and
APL (at least) preceded THAT.  People who expect to do an element-by-element
translation of procedural programs into functional languages remind me of the
proverbial tourist, who is sure that if he speaks English loudly and slowly
enough, the natives will figure it out.
     Or, as I heard somebody complain at an early OS/2 demonstration:  "If IBM
has to use UNIX to explain what it does, why isn't it UNIX?"  You could use
FORTRAN to explain how some features of J work, but if you do then I don't
think you can claim that your audience is learning about J.

     There is some sense in which J verbs RESEMBLE functions.  But adverbs are
an important part of J; they're somewhat analogous to adverbs in English and
unlike any feature in most other programming languages.  (Okay:  They resemble
what APL manuals call `operators', and don't resemble what C manuals call
`operators'.  Calling them `operators' in J would, I think, lull people who
somehow find the term `adverb' intimidating into believing that they understand
them.)

     There used to be (and for all I know there still is) a recurring pattern
of people learning APL as a notation, and continuing to think and program
essentially in FORTRAN (or C, or whatever).  The conceptual breakthrough, into
using APL "as a tool of thought" happened 4-8 months down the road, if ever.
I'm not as certain as I would like to be that this is a Bad Thing.  However,
I can see that if J encouraged this in any way, it would tend to get compared,
AS A NOTATION FOR PROCEDURAL PROGRAMMING, against the 300 (or 3000, or however
many) block-structured procedural languages already extant.  Compared, found
wanting, and discarded.
     The only way that I can see the innovations in J getting a "fair hearing"
is if programmers cannot avoid them.  It seems to me that this is exactly the
flipside of the argument for using the ASCII character set:  people cannot
reject J for its character set demands, but must judge it on its actual merits.

     I do not claim to KNOW why the J materials take the approach that they do.
But I can clearly see reasonable arguments for deliberately doing things that
way, and against providing the sort of "tourist's phrasebook" manual.


+------------------
| Peter S. Shenkin
| <1991Nov10.190838.14635@ctr.columbia.edu>

In article <1991Nov9.001252.6288@yrloc.ipsa.reuter.COM>
 dgil@ipsaint.ipsa.reuter.COM (Gillett, David) writes:

>     Mark Keil pleads for material that would explain J in terms of "how you do
>things in other languages".  I have some mixed feelings about this.

>  ...People who expect to do an element-by-element
>translation of procedural programs into functional languages remind me of the
>proverbial tourist, who is sure that if he speaks English loudly and slowly
>enough, the natives will figure it out.

>... There is some sense in which J verbs RESEMBLE functions.  But adverbs are
>an important part of J; they're somewhat analogous to adverbs in English and
>unlike any feature in most other programming languages....

>... There used to be (and for all I know there still is) a recurring pattern
>of people learning APL as a notation, and continuing to think and program
>essentially in FORTRAN (or C, or whatever).  The conceptual breakthrough, into
>using APL "as a tool of thought" happened 4-8 months down the road, if ever...


Dave,  In one sense I agree with you.  I actually happened to learn
to program the other way around.  I learned APL first, and used it for
several years before, out of necessity, rather than desire, I learned to use
C, Fortran, and even UNIX.  Therefore I really looked forward to getting
J and learning to use it.  But I found that even with my background
I cannot grok the J documentation or the language.  I spent about eight
hours with it and a working version of the program, and got so frustrated
that I gave up.  In that eight hours I did not expect to learn the language,
but I did expect to learn enough so that I could do a few simple things,
and to bootstrap myself into a position so that I could learn the next
things more easily than the first things.

Telling the user how to do things in J that he already does in other languages
does not mean telling him how to write a DO-loop in J.  It means showing
him how to do in idiomatic J what he now uses a DO-loop for in Fortran.
The mapping isn't one-to-one;  sometimes a Fortran user uses a DO-loop
to initialize an array to 0's, or, say, to the DO variable, so here one
would give the J operations to do these things.  Sometimes it's used to
take dot products, or, in nested form, to multiply matrices; again, one
would show how these things are done with primitive operations in J.

IF()THEN...ELSEIF()THEN....ENDIF constructs also have different purposes
which would be met with different constructs in J.  Examples can be laid
out.

The methods of doing most of the above things are very similar, I gather,
(though please tell me if I am wrong) in APL and in J;  for example, there
is a one-to-one correspondence, or nearly so, between APL's RHO and IOTA
and their J equivalents.

On the other hand, in APL there is a method for indexing into an array to
set or extract specific subarrays or elements.  I gather that in J some very
different mechanism is used, but I have not been able to figure out from a
combination of the documentation and playing with the program what J's
mechanism is and how it works.

That's why I said in a previous posting that, for me, a useful book might
have a title like "J for APL Users."  For the stuff mentioned earlier, a
useful book might have a title like "J for Users of Procedural Languages."
And I don't think the best person to write such a book would necessarily
be an expert in J, like Hui or Bernecky or Sirlin.  The best person to write
such a book might be someone who has just learned J the hard way, and still
remembers what he had to unlearn.  (This goes for technical manuals in general.)

>... I do not claim to KNOW why the J materials take the approach that they do.
>But I can clearly see reasonable arguments for deliberately doing things that
>way, and against providing the sort of "tourist's phrasebook" manual.

Maybe there are folks out there who have either the patience, the
intelligence or the genetic endowment to learn J given the program and
the existing docs.  All I can say is that so far, I'm not one of them.
I have a feeling, though, that with different sorts (note, I am not saying
"better") learning materials, a greater audience might be reached, and that
people like me might even be a member of that greater audience.


+------------------
| David Feustel
| <1991Nov10.221515.13419feustel@netcom.COM>

I've worked enough with APL to have no problem with array operators and
generators. My problem with J is two-fold:

First, I see no obvious way to organize J code into a set of tidy
bundles equivalent to functions and subroutines in Fortran or C.

Second, there are times when you want to handle a volume of input that
is too large to fit in memory. It is then necessary to read the data
in a bit at a time, process it, then write it out. I don't yet see
how this would be done in J.

In 1983 worked with an APL variant called PL/PC which eliminated line
numbers but introduced DO-WHILE, IF-THEN-ELSE-ENDIF etc. control


structures, complex numbers and alpha symbols for all the APL operators.
I found this variant of APL extremely useful and I wish I could get the
source code for this product since the company selling it (Creative Software
(Philip Wong, Director) in Australia) is now unreachable by me.


+------------------
| David Feustel
| <1991Nov10.223306.13974feustel@netcom.COM>

I would also add that I think most people with mathematical
backgrounds would benefit from an into to J that made no analogies to
English grammar. On the one hand the use of language in the J
documentation compares(favorably) with Buckminster Fuller's style.
On the other hand I think an operator/operand approach with additional
explanations for the effects possible with "adverbs" and "gerunds"
would be more effective.


+------------------
| Roger Hui
| <1991Nov11.065400.27418@yrloc.ipsa.reuter.COM>


Raul Deluth Miller-Rockwell writes:
    ...
> For example, I read in a magazine today about Fermant's Little
> Theorem, and wasn't sure if I was getting the point, so I wrote a
> little code to test it out for a variety of test cases.  First, I
> tried some APL code:
>     _
>     V R <- A FLT P
> [1] _ R <- P|_1+A*P-1
>     V
>
> Playing around with that a little, I find that if P is a prime, and if
> A is prime with respect to P, that R is zero.  ...
>               ...            I thought I'd try it in J -- just to get a
> feel for how J deals with this sort of thing.
>
>    flt =. '' : '  y. ] _1 + x. ^ y. - 1 '  " 0
>    t flt/ t =. 2 3 5 11 13 17 19 23 29
> 1 0 0 0  0 0 0 0 0 0
> 0 2 0 0  0 0 0 0 0 0
> 0 0 4 0  0 0 0 0 0 0
> 0 0 0 6  0 0 0 0 0 0
> 0 0 0 0 10 0 0 0 0 0
> 0 0 0 0  0 0 0 0 0 0
> 0 0 0 0  0 0 0 0 0 0
> 0 0 0 0  0 0 0 0 0 0
> 0 0 0 0  0 0 0 0 0 0
> 0 0 0 0  0 0 0 0 0 0
>
> Ok, so first off it's obvious that J doesn't support arbitrarily large
> integers.  At least not yet.  Second off, it looks like J does a
> pretty good job of avoiding roundoff error, at the expense of a little
> precision.  [I'd expect that diagonal to be primes minus 1:  1 2 4 10
> 12 16 18 22 28 ..., and it looks like the 12 was sacrificed to detect
> floating point errors -- though this might be an artifact of different
> floating point architectures on the two machines I was using.]
>
> So I think this exemplifies one of the "design decisions of J" --
> accuracy over precision.  [But if I'd skipped this entire digression,
> except for the preceeding sentence, what would you have thought?]

Raul, I realize that you are making a point about trade-offs between
accuracy and precision.  On the topic of Fermat's Little Theorem alone:

Without too much extra work, it is possible to devise better tests
of the conjecture that the non-diagonal elements are zero, and the
diagonal elements are primes minus 1.  For integers a and b:

a. a&| distributes over *; that is, a|b*c  is  a|(a|b)*(a|c) .
b. Power is repeated multiplication.  That is, a^b is a&*^:b 1
   (b is non-negative.)


Therefore:

   p=.2 3 5 7 11 13 17 19 23 29 31 37 41 43 47

   fltm =. '' : 'y.|_1+(y.&])@(x.&*)^:(y.-1) 1' " 0
   fltm/~p
1 0 0 0  0  0  0  0  0  0  0  0  0  0  0
0 2 0 0  0  0  0  0  0  0  0  0  0  0  0
0 0 4 0  0  0  0  0  0  0  0  0  0  0  0
0 0 0 6  0  0  0  0  0  0  0  0  0  0  0
0 0 0 0 10  0  0  0  0  0  0  0  0  0  0
0 0 0 0  0 12  0  0  0  0  0  0  0  0  0
0 0 0 0  0  0 16  0  0  0  0  0  0  0  0
0 0 0 0  0  0  0 18  0  0  0  0  0  0  0
0 0 0 0  0  0  0  0 22  0  0  0  0  0  0
0 0 0 0  0  0  0  0  0 28  0  0  0  0  0
0 0 0 0  0  0  0  0  0  0 30  0  0  0  0
0 0 0 0  0  0  0  0  0  0  0 36  0  0  0
0 0 0 0  0  0  0  0  0  0  0  0 40  0  0
0 0 0 0  0  0  0  0  0  0  0  0  0 42  0
0 0 0 0  0  0  0  0  0  0  0  0  0  0 46

[[NB. sws. The result may depend on the machine. On my sun sparc I get
1 0 0 0  0 0 0 0 0 0 0 0 0 0 0
0 2 0 0  0 0 0 0 0 0 0 0 0 0 0
0 0 4 0  0 0 0 0 0 0 0 0 0 0 0
0 0 0 6  0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 10 0 0 0 0 0 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0 0 0 0 0 0
0 0 0 0  0 0 0 0 0 0 0 0 0 0 0
]]
Alternatively, if b is a power of 2, a^b can be obtained by
repeated squaring, i.e. by *:^:(2^.b) a.  Therefore:

   exp  =. (# i.@-@#)@#:    NB.  y = +/2^exp y
   flts =. '' : 'y.|_1 + (y.&|)@*/ (y.&|)@*:^:(exp y.-1) x.' " 0
   (flts/~ -: fltm/~) p
1
[[NB. sws.  I get 0 here, since flts gives Hui's result above (all the
diagonals) ]]

Last December, Roger Moore, motivated by his use of Mathematica
(in particular PowerMod[]), suggested the following variant of ^ :

   x ^!.m y   is   m]x^y

with the understanding that the residue is taken after every
multiplication, as is done in "fltm" above.  (!. is the "fit",
"custom", or "variant" conjunction.)


+------------------
| Michael J. A. Berry
| <MJAB.91Nov11132830@thoon.think.com>

In article <1991Nov9.044006.8504@yrloc.ipsa.reuter.COM>
 hui@yrloc.ipsa.reuter.COM (Roger Hui) writes:

   I would not characterize function or verb definition this way.  In my
   own work, explicit definition is hardly ever used; most defns are tacit.
   See the paper by McDonnell, Iverson, and myself in the APL 91 conference
   proceedings.  The paper has numerous examples of tacit defn, including
   tacit defns in J of APL functions from the FinnAPL Idiom Library.
   The article on "Tree Representation" I posted to this group on
   1991 9 27 also illustrates this style.

   --------------------------------
   Roger Hui, Iverson Software Inc., 33 Major Street, Toronto, Ontario  M5S 2K9
   (416) 925 6096; Fax: (416) 488 7559

This is only one of several recommendations to read an article in the
proceedings of APL-91 that I have seen.


+------------------
Joseph. W. Davison
| Date: Tue, 12 Nov 1991

In article <1991Nov9.042909.8290@yrloc.ipsa.reuter.COM>
 hui@yrloc.ipsa.reuter.COM (Roger Hui) writes:
>Re comments from Joseph W. Davison.
>
>It seems unreasonable to complain about " "hook" and "fork" and other
>amazing but obscure references" on the one hand, and to decline to
>obtain the available documentation on the other.

Touche!
I was not actually "complaining," rather, "commenting."  I have not
declined to obtain the available documentation, but have yet done so; I
probably  will, when it becomes important to me.

>Regarding the fears
>about the documentation.  Yes, there are definite dangers:  one might
>actually learn something, and invincible ignorance will cease to be
>available as a defense.
>

True enough, but unassailable arrogance is hardly an appropriate
response to a potential customer's comment "I find the on line help
obscure." I've expended a little time in finding references that help
in relieving that "I'm missing something" feeling I was responding to.
Your reply would have been more helpful if it had provided the
reference I was fumbling for.

Don't get me wrong, I like what I've seen in J; and have no desire to
trade insults.  The comment "amazing but obscure" is, I think, an
appropriate description, and is meant to be a compliment. I'm sure that
buying the book and studying it will enable many programmers, probably
even me, to master the language.  But, I dropped into this newsgroup in
the middle of some of the recent examples, and I'll assure you that
[removing the syntactic ambiguities from APL, so that whitespace is no
longer needed to allow parsing] has not improved readability by passers
by  -- In case you were wondering, J ain't COBOL, which was designed to
allow nonprogrammers to read it.  That's not critism, that's fact!  You
may even be proud of it :-)    J looks like fun! I'll play with it a
while.


+------------------
| Mark Keil
| <1991Nov13.221530.2496@apollo.hp.com>

The responses have been helpful.  I plan to keep asking questions.
Below I respond to a number of the messages in the last few days.

My Thanks to  Roger Hui, David Gillett, David Feustel,  Peter S. Shenkin, &
 Michael J. A. Berry

 Roger Hui  writes
 >
 >Mark Keil writes:
 >
 >> In cahpter 1, section B there is the sentence:
 >>  "Do not attempt to read it [the dictionary -keil]
 >>   as an introduction to the language; to do so might
 >>   prove as frustrating as reading a full French dictionary
 >>   to learn french"
 >>
 >> I agree with this statement. The catch [22] of this is that
 >> one has to buy the book [Prog in J] to find this out. As far
 >> as I can remember this isn't stated in the catalog or in the
 >> dictionary... So for the rest od you who havn't gotten
 >> Programming in J yet, I recommend that you get it.
 >
 >There is no Catch-22.  The opening sentence of the third paragraph
 >in the dictionary says:  "A dictionary should not be read as an
 >introduction to a language, but should rather be consulted with other
 >materials such as Appendix B and References 4-5".  Appendix B are
 >the tutorial frames; reference 4 is "Programming in J"; and reference
 >5 is "Tangible Math".

Friday night, I saw that paragraph in the dictionary. It is there. Is is not as
strong a statement as in "Programmming in J" however.

I should have been more clear. The difficulty started when I read the
readme.doc file in the distibution file for the mac version of J.
(version 3.2 .  I have since the 3.4 version from ISI, same story I believe)

In it it states:
"Registered users receive a printed manual and notice of new releases.
To order or register your copy, send $24 to:"
This file doesn't tell one that the "manual" is the dictionary & tangible math,
 doesn't mention that "Programming in J" is also available, or that
"Programming in J" is highly desireable/necessary.
(to be very clear, [for this article] the above quote came from the sun
tar file, and is identical [I beleive] to the mac version)

To reduce others confusion in the future, may I suggest/request that the
readme.doc file be updated in the distribution materials.
I would also suggest the inclusion of an order form to make it easier
for people to register/order J material.


 Roger Hui  writes
 >
 >Learning J from the dictionary proper could be a challenge.  However,
 >almost half of the dictionary booklet consists of tutorial frames,
 >and it is possible to get a good feeling for the language by
 >studying these tutorial frames (and the material in "Tangible Math").
 >In other words, the material sent to registered users does make
 >possible a start on using the language.
 >
 >> Even so, I still feel that I'm missing something. I just can't
 >> put my finger on it.  ...
 >>
 >> I suspect that hearing the "WHY" for many aspects of the language,
 >> would also help me to understand.
 >
 >On the "why" of APL and J, the dictionary points the reader to references
 >1-3 (last sentence, second paragraph).  If you are interested in such issues
 >it may be worthwhile to follow up on these references.  References 1-3 are:
 >
 >1. Falkoff, A.D., and K.E. Iverson, The Design of APL,
 >IBM Journal of Research and Development, 1973 7; and The
 >Evolution of APL, ACM SIGPLAN Notices, 1978 8.
 >
 >2. Hui, R.K.W., K.E. Iverson, E.E. McDonnell, and A.T. Whitney,
 >APL\?, APL 90 Conference Proceedings, APL Quote-Quad, Volume 20,
 >Number 4, 1990 8.
 >
 >3. Iverson, K.E., A Dictionary of APL, ACM APL Quote-Quad,
 >Volume 18, Number 1, 1987 7.

I have gotten "The Design of APL". It is interesting in its own right
but hasn't helped me much with J.

I had ordered the other references, but I have no idea when they will arrive.
ISI has proved be very timely in response to orders. May I suggest/request
that ISI sell a package of reprints that are in the references list?
I feel that this could be very helpful, particularly for folks who don't
have access to libraries with interlibrary loan capibility.


 David Gillett  writes:
 >

 >  ...People who expect to do an element-by-element
 >translation of procedural programs into functional languages remind me of the
 >proverbial tourist, who is sure that if he speaks English loudly and slowly
 >enough, the natives will figure it out.

I'd like to speak J.  And, since the natives seem to know many languages, I'd
 like
them to patiently explain it to me. Since the written material is in some
 dialect
such that I frequently miss the meaning, I've had to ask for similies in some
of the languages I know :-)   Maybe I need the unwritten guide to the dialect
 :-)

Actually the foreign language analogy is pretty good. If one is not born into a
language, one either has to learn it cold (very difficult) or with the aid of
interpreters/teachers. So one learns the forms & idioms of the new language
in terms of the old. The translationis are often a poor fit, and it take a LONG
time to become an idomatic speaker. It is much less bewildering than learning a
foreign language cold.

 >  {stuff deleted}
 >
 >     There used to be (and for all I know there still is) a recurring pattern
 >of people learning APL as a notation, and continuing to think and program
 >essentially in FORTRAN (or C, or whatever).  The conceptual breakthrough, into
 >using APL "as a tool of thought" happened 4-8 months down the road, if ever.

I expect that it may take 4-8 months before J "clicks" and I can think that way.
I know the phenomenon, APL was the 5th language that I learned, and it
took a while to "click".

Since I've learned other languages before J, and since learning J from the
documentation as has been so difficult using the direct approach, I have looked
for a bridge to understanding via comparison to other languages.

 >I'm not as certain as I would like to be that this is a Bad Thing.  However,
 >I can see that if J encouraged this in any way, it would tend to get compared,
 >AS A NOTATION FOR PROCEDURAL PROGRAMMING, against the 300 (or 3000, or however
 >many) block-structured procedural languages already extant.  Compared, found
 >wanting, and discarded.
 >     The only way that I can see the innovations in J getting a "fair hearing"
 >is if programmers cannot avoid them.  It seems to me that this is exactly the
 >flipside of the argument for using the ASCII character set:  people cannot
 >reject J for its character set demands, but must judge it on its actual
 merits.

On the other hand, if the langauge is intractable beacuse the documentation is
insufficient, then many people may just drop it thinking that the language
is to complex. My intuition tells me that J is elegant and very powerful, and
that I just havn't seen from an angle where it is all clear.

It'a also interesting to consider that it's name (J) is a bit cryptic, and
 perhaps
may be imposing to some. J isn't exactly a freindly name like BASIC or ABC.

 >     I do not claim to KNOW why the J materials take the approach that they
 do.
 >But I can clearly see reasonable arguments for deliberately doing things that
 >way, and against providing the sort of "tourist's phrasebook" manual.

Hmmmmm, I wonder what the philosophy behind the J materials structure is?
Anybody care to speculate?


 Roger Hui  writes:
 >
 >Mark Keil writes:
 >
 >> I would like to see sentences like: "Explicit definition of Verbs is a more
 general
 >> and powerful implementation of the concept of function definition. Be
 careful that
 >> you don't equate function definition with Explicit definition of Verbs
 because this
 >> could limit your ability to conceptualize Explicit definition."
 >> [Raul & Roger, is the above summary correct?]
 >
 >I would not characterize function or verb definition this way.  In my
 >own work, explicit definition is hardly ever used; most defns are tacit.
 >See the paper by McDonnell, Iverson, and myself in the APL 91 conference
 >proceedings.  The paper has numerous examples of tacit defn, including
 >tacit defns in J of APL functions from the FinnAPL Idiom Library.
 >The article on "Tree Representation" I posted to this group on
 >1991 9 27 also illustrates this style.

Well, how WOULD you characterize function or verb definition?

And what can you tell me about these boxed things?
  1. In general?
  2. What are their properties?
  3. What are they good for?



 Roger Hui  writes
 >
 >David Feustel writes:
 >
 >> What I still haven't comprehended is what J's control structures are.
 >> At present I see the language as a very effective tool for generating
 >> arrays, matrices and vectors with a few keystrokes. I cannot see this
 >> language being used for serious programming.
 >
 >Hmm, what is serious programming, if it is not "generating arrays,
 >matrices, and vectors"?  Moreover, it seems rather abrupt
 >to pronounce the language unsuitable for serious programming,
 >without comprehension of what the "control structures" are.
 >
 >The following are a few examples of "control structures".
 >(u and v are verbs; m and n are nouns.)
 >
 >u/
 >For example, +/ is summation and */ is product.  These are DO loops
 >in C or Fortran, commonly written for arrays of particular ranks
 >(whereas +/ works on arrays of any rank).
 >
 >u\ and u\.
 >For example, +/\ are sums of prefixes and +/\. are sums of suffixes.
 >These are DO loops in C or Fortran.
 >
 >u/.
 >The monad applies u to the oblique lines of the argument; the dyad
 >x u/. y applies u to items of y having the same keys as specified by x.
 >These are DO loops in C or Fortran.
 >
 >u"n
 >Apply u to the rank n subarrays of the argument.  For example, +/"1
 >sums the lists in the argument.  This is a DO loop in C or Fortran.
 >
 >u^:n
 >Apply u to the argument n times.  (u^:_ is the limit of the application
 >of u.)  This is a DO loop in C or Fortran.
 >
 >u&v and u@v
 >Compose u and v.  These are the {} and s0;s1;s2; constructs in C.
 >
 >u0`u1`u2` ... `un @. v
 >Apply one of the verbs u to the argument(s), according to the index
 >computed by applying v to the argument(s).  For example,
 >   fac =. 1:`(* fac@<:) @. *
 >defines the factorial function.  This is the if-then-else and
 >switch-case constructs in C.
 >
 >m u n
 >Applies u to m and n, for arrays m and n of any rank.  For example,
 >m+n adds m to n for conformable arrays m and n, whether m and n
 >have one element or one million elements.  These are DO loops in C
 >or Fortran.

This stuff is great! I'd like to see more like it. AND (for me) it doesn't
have to actually compare it to another language, thought this can be helpful.
It is VERY helpful to have a discription, rather than just an executable string
and the results.

 >
 >... and many more.  Moreover, these facilities can be composed in
 >well-defined and consistent ways (as in +/\, +/\., and +/"n).
 >
 >What are the control structures in J?  Answer: Everything.

This sentance is a gem!  It is obviously true, and yet isn't explicitly stated
 anywhere
(that I can remember). It is very helpful to see it anyway.
Do you have any more of these Roger?


 Peter S. Shenkin writes
 >
 >In article <1991Nov9.001252.6288@yrloc.ipsa.reuter.COM>
 dgil@ipsaint.ipsa.reuter.COM (Gillett, David) writes:
 >
 >>     Mark Keil pleads for material that would explain J in terms of "how you
 do
 >>things in other languages".  I have some mixed feelings about this.
 >
 >>  ...People who expect to do an element-by-element
 >>translation of procedural programs into functional languages remind me of the
 >>proverbial tourist, who is sure that if he speaks English loudly and slowly
 >>enough, the natives will figure it out.
 >
 >>... There is some sense in which J verbs RESEMBLE functions.  But adverbs are
 >>an important part of J; they're somewhat analogous to adverbs in English and
 >>unlike any feature in most other programming languages....
 >
 >>... There used to be (and for all I know there still is) a recurring pattern
 >>of people learning APL as a notation, and continuing to think and program
 >>essentially in FORTRAN (or C, or whatever).  The conceptual breakthrough,
 into
 >>using APL "as a tool of thought" happened 4-8 months down the road, if
 ever...
 >
 >
 >Dave,  In one sense I agree with you.  I actually happened to learn
 >to program the other way around.  I learned APL first, and used it for
 >several years before, out of necessity, rather than desire, I learned to use
 >C, Fortran, and even UNIX.  Therefore I really looked forward to getting
 >J and learning to use it.  But I found that even with my background
 >I cannot grok the J documentation or the language.  I spent about eight
 >hours with it and a working version of the program, and got so frustrated
 >that I gave up.  In that eight hours I did not expect to learn the language,
 >but I did expect to learn enough so that I could do a few simple things,
 >and to bootstrap myself into a position so that I could learn the next
 >things more easily than the first things.
 >

At least I not the only one having trouble with this stuff. I wonder if
knowing APL is a help or hinderence? probably both...

 >Telling the user how to do things in J that he already does in other languages
 >does not mean telling him how to write a DO-loop in J.  It means showing
 >him how to do in idiomatic J what he now uses a DO-loop for in Fortran.
 >The mapping isn't one-to-one;  sometimes a Fortran user uses a DO-loop
 >to initialize an array to 0's, or, say, to the DO variable, so here one
 >would give the J operations to do these things.  Sometimes it's used to
 >take dot products, or, in nested form, to multiply matrices; again, one
 >would show how these things are done with primitive operations in J.
 >

I would prefer to learn the J idioms. I prefer to think in data aggragates,
and I prefer to avoid all the systatic overhead of loop control. The analogys
are helpful to show that the essence can be captured it a simpler and more
elegant form.

 >IF()THEN...ELSEIF()THEN....ENDIF constructs also have different purposes
 >which would be met with different constructs in J.  Examples can be laid
 >out.
 >
 >The methods of doing most of the above things are very similar, I gather,
 >(though please tell me if I am wrong) in APL and in J;  for example, there
 >is a one-to-one correspondence, or nearly so, between APL's RHO and IOTA
 >and their J equivalents.
 >
 >On the other hand, in APL there is a method for indexing into an array to
 >set or extract specific subarrays or elements.  I gather that in J some very
 >different mechanism is used, but I have not been able to figure out from a
 >combination of the documentation and playing with the program what J's
 >mechanism is and how it works.

It looks like you want:  from, take & ammend. An elegant scheme. Now if only
I rally understood frames and rank-k cells. I've read about it in nouns
(page 2 of the dictionary), but I lack the referants for it to be clear.

 >
 >That's why I said in a previous posting that, for me, a useful book might
 >have a title like "J for APL Users."  For the stuff mentioned earlier, a
 >useful book might have a title like "J for Users of Procedural Languages."
 >And I don't think the best person to write such a book would necessarily
 >be an expert in J, like Hui or Bernecky or Sirlin.  The best person to write
 >such a book might be someone who has just learned J the hard way, and still
 >remembers what he had to unlearn.  (This goes for technical manuals in
 general.)
 >

Oh, Peter, I think you are very right about the best person write such a book.

 >>... I do not claim to KNOW why the J materials take the approach that they
 do.
 >>But I can clearly see reasonable arguments for deliberately doing things that
 >>way, and against providing the sort of "tourist's phrasebook" manual.
 >
 >Maybe there are folks out there who have either the patience, the
 >intelligence or the genetic endowment to learn J given the program and
 >the existing docs.  All I can say is that so far, I'm not one of them.
 >I have a feeling, though, that with different sorts (note, I am not saying
 >"better") learning materials, a greater audience might be reached, and that
 >people like me might even be a member of that greater audience.
 >
 >      -P.

I agree on the organization and format of the materials. I also suspect that you
can do it with the current materials. It will just take longer.

 >Michael J. A. Berry writes
 >
 >>In article <1991Nov9.044006.8504@yrloc.ipsa.reuter.COM>
 hui@yrloc.ipsa.reuter.COM (Roger Hui) writes:
 >>
 >>   See the paper by McDonnell, Iverson, and myself in the APL 91 conference
 >>   proceedings.  The paper has numerous examples of tacit defn, including
 >>   tacit defns in J of APL functions from the FinnAPL Idiom Library.
 >>   The article on "Tree Representation" I posted to this group on
 >>   1991 9 27 also illustrates this style.
 >
 >This is only one of several recommendations to read an article in the
 >proceedings of APL-91 that I have seen.  Does anyone out there in net land
 >know when these proceedings are likely to be sent out to loyal sigapl
 >members such as myself?  After all, it will soon be 1992.

I've requested this reference from my librarian. Is it available? Anybody know?
If it's not available, can I get a copy from you Roger?


+------------------
| Gillett, David
| <1991Nov13.231507.9873@yrloc.ipsa.reuter.COM>

     I recall the first time I tried to learn C.  It was around 1976-7, and K&R
was all that there was.  ("The C Programming Language", by Kernighan and
Ritchie.  A second edition describes the language as standardized by ANSI.)
     Major concepts of the language consistently eluded me.  I gave up in
disgust, and didn't look at it again for 3-4 years.  But I did learn a heck of
a lot in those years, and when I came back to C it all made a great deal of
sense.
     Would an "Introduction to C for FORTRAN Programmers" have helped me?  I
don't think so; the concepts that I needed went much deeper than the syntactic
differences between C and FORTRAN.


+------------------
| Roger Hui
| <1991Nov14.045427.12325@yrloc.ipsa.reuter.COM>

David Feustel writes:

> I've worked enough with APL to have no problem with array operators and
> generators. My problem with J is two-fold:
>
> First, I see no obvious way to organize J code into a set of tidy
> bundles equivalent to functions and subroutines in Fortran or C.
>
> Second, there are times when you want to handle a volume of input that
> is too large to fit in memory. It is then necessary to read the data
> in a bit at a time, process it, then write it out. I don't yet see
> how this would be done in J.

I happen to be working on a problem which is somewhat relevant.
In writing a program logic manual for J, I needed to find all the names
#define'd in the *.h C source files.  The lines of interest are of the form:
   #define<blank>name<blanks><stuff>
   #define<blank>name(<stuff>)<blanks><stuff>

The solution is in the form of a script, "analh.js", whose contents are:
   junk =. a.-.lf,'(),#_ 0123456789',(,65 97+/i.26){a.
   sel  =. ''&[`((<./@(i.&'( ') {. ])@(8&}.)) @. ('#define '&-:@(8&{.))
   def  =. -.&(<'') @ (<@sel;._2) @ (-.&junk) @ read

There are some handy definitions previously saved under the script
"xnames.js":
   lf     =. 10{a.
   host   =. 0!:0
   read   =. 1!:1
   write  =. 1!:2
   append =. 1!:3
   iread  =. 1!:11
   iwrite =. 1!:12
         ...
and the script "dir.js" (IBM PC directory):
   mdir   =. }: @ (4&}.) @ (12&{.;._2) @ host @ ('dir '&,)
   bxd    =. ({&12 8)@(' '&=)@(9&{"1) <@(-.&' ')@{."_1 '.'&(8&{"1})
   dir    =. (-.&('..';,'.')) @ (/: >) @ bxd @ mdir

To get the list of #define-d names,
a. Execute the scripts "xnames.js", "dir.js", and "analh.js".
b. Execute the line    x=. ~. (/:>) ; <@def dir '*.h'

dir '*.h' returns a list of file names, individually boxed.
(The defn of "dir" is system-dependent.  For example, on UNIX
dir =. <;._2 host 'ls *.h'  .)

[[NB. sws.  This works with the line (b.) above
   dir =. '<;._2 host ''ls '',y.' :11
]]

<@def is applied to each boxed file name (apply "def" to each name,
and box the result).  ; gathers the boxed "def" results into one long
list of boxed names.  (/:>) sorts this list.  ~. removes any duplicates.

"def" takes a boxed file name argument and returns a list of boxed
#define-d names.  First, the entire file is read.  Then, "junk"
characters are removed.  The result consists of lines ending in lf.
<@sel is applied to each line.  Empty names are removed.

"sel" extracts a #define-d name from a line.  If the line does
not begin with "#define ", the result is simply the empty string.
Otherwise, drop the first eight characters of the line (i.e. drop
"#define "), then take the portion of the line up to but not including
the first blank or "(".

Final comments:

a. In this application, the "tidy bundles equivalent to functions
and subroutines in Fortran or C" can either be the defined verbs
("def", "sel", etc.), or the scripts.

b. If space were a problem, I could have appended each result to
a file as it became available, i.e.
   append&(<'outfile')@(,&lf)@sel;._2     instead of   <@sel;._2
      or


   append&(<'outfile')@;@:(,&lf&.>)@def   instead of   <@def
or else used "iread" instead of "read".

c. Those interested in comparisons can solve the problem specified
in the opening paragraph in their favorite APL dialect, C, Fortran,
etc., then compare their solutions to the solution in this msg.


+------------------
| David Feustel
| <1991Nov14.131623.19665feustel@netcom.COM>

keil@apollo.hp.com (Mark Keil) writes:

> Roger Hui  writes
> >The following are a few examples of "control structures".
> >(u and v are verbs; m and n are nouns.)
> >
> >
> >u^:n
> >Apply u to the argument n times.  (u^:_ is the limit of the application
> >of u.)  This is a DO loop in C or Fortran.

I think I understand this. An example would probably drive it home.

> >
> >u&v and u@v
> >Compose u and v.  These are the {} and s0;s1;s2; constructs in C.
> >
> >u0`u1`u2` ... `un @. v
> >Apply one of the verbs u to the argument(s), according to the index
> >computed by applying v to the argument(s).  For example,
> >   fac =. 1:`(* fac@<:) @. *
> >defines the factorial function.  This is the if-then-else and
> >switch-case constructs in C.
> >

This is exactly what I was hoping to get to clear up my confusion.
This text with examples added would go a long way toward making J
easier for people with programming background easier to grasp.

Now, about those tacit(?) definitions...


+------------------
| Tom Affinito
| <2271@rosie.NeXT.COM> 14 Nov 91

I've been following this thread for a bit and thought I'd jump in:

1) I believe that J is a language under development, and most of the
documentation we have seen so far is intended for that (small) population that
is familiar with the progress of advanced APL features. The Dictionary is not
complete...it references other papers for the specifics of some numerical
operations, and these papers are not readily accessible for those not near a
large University library, or a well-stocked APL club.

2) I have faith that as the language settles down we will see more
user-friendly documentation and programming guides. I am not upset that these
books do not exist yet...I consider it a privilege that I can peek in on the
development of such a cool language. I do not believe that current docs can
teach a non-APLer to program in J.

3) What I would like to see are small (15 to 20 line) problems being
solved...problems that indicate styles for verb writing, splitting logic
between noun state and verb logic, uses of tacit defs and gerunds, etc. People
have posted large examples in the past...this is great, but I think that a
great aid to help explain the "hidden logic" of a language is by working
through several "reasonable" examples. The J docs by and large only provide
one-liners....I think that the J-literates and J-wannabe's on the net can
provide a great service through generating and debugging such problems.

[Ex: in C, arrays and for-loops are connected concepts in the programmers
head...these concepts got connected through his experience with paradigmatic
sample programs, not through his reading of a terse reference manual, and not
because of any innate "obviousness". CACM in Sept 86 had some good articles on
"teaching language" issues for those who want more detail. It is exactly the
lack of paradigmatic code samples that I think is hindering the development of
J "literacy".]

4) Summary. Those producing J doc at ISI have their own technical agenda, and
producing high-quality instructional material is not it. I believe this is as
it should be AT THIS TIME...What can we do on the net until we get domain
experts to develop such an instructional curricula? We can program in public,
in front of our peers. Submit what we think to be quality "textbook" solutions
to small problems (small so other netters can get involved w/o a large time
commitment), using the best style possible (ie, readable var names, comments,
etc), and have the solution improved through consensual net critque. Possible
small problems...simple file parser that reverses the letter order of each
line, small biorhythm program illustrating interactive terminal operators
(maybe with terminal graphics...ok, this is not a small program, but it could
be patched together from perhaps three small programs), a small graphic library
illustrating workspace name choices and given names, etc (all these just off
the top of my head)...


+------------------
| David Feustel
| <1991Nov14.192624.7281feustel@netcom.COM>

Now we're really getting somewhere! I've been conceptuallizing J as a
high-level microprogramming language where you roll your own
application-specific functions. Is there a way to invoke J with a
command line option that specifies a workspace to be loaded in
automatically?


+------------------
| David Feustel
| <1991Nov14.204636.11703feustel@netcom.COM>

I just typed in Roger Hui's examples and things don't quite work. It
could well be that I made errors while typing in the definitions. An
idea from HP48sx land came to mind: have the =. and =: operators print
out a CRC of the definition so that the accuracy of the input can be
checked easily.


+------------------
| Raul Deluth Miller-Rockwell
| <ROCKWELL.91Nov16011659@socrates.umd.edu>

Tom Affinito:
   3) What I would like to see are small (15 to 20 line) problems
   being solved...problems that indicate styles for verb writing,
   splitting logic between noun state and verb logic, uses of tacit
   defs and gerunds, etc. People have posted large examples in the
   past...this is great, but I think that a great aid to help explain
   the "hidden logic" of a language is by working through several
   "reasonable" examples. The J docs by and large only provide
   one-liners....I think that the J-literates and J-wannabe's on the
   net can provide a great service through generating and debugging
   such problems.

Well, as a poster of such examples, I can say that it's rather
difficult to verbalize all of the thoughts that go into writing a
program.  Furthermore, much of the thinking is simply a re-statement
of what each primitive does, or a set of "proto-typical" examples...

Actually, from my point of view, the thing that seems to generate the
most interest is a set of obvious (and perhaps not so obvious)
blemishes.  Then, clever people can say "Aha!  I can see how to do
that better."  And maybe in the process they learn something.

Fortunately, I'm quite adept at putting such blemishes into my posts.
:-)

   Possible small problems...simple file parser that reverses the
   letter order of each line,

You mean like
   read=.   1!:1
   append=. 1!:3 <
   nl=. 10{a.
   (=&nl  append&'outfile'@ (,&nl)@ |. ;._2 [) read <'infile'
???
[[NB. sws.  This doesn't quite work... I'd use
   rv=. '((,&nl)@|.) &.> (<;._2 y.,nl)' :11
   (append&'outfile') ,> rv read <'infile'
]]
There isn't much to this:  read the file, cut it up on line
boundaries, reverse each line, add a trailing newline to each line,
and stick it back out on file.  You could get rid of the (,&nl)@  if
you changed the ;._2 to a :.2, and didn't mind that your newlines had
moved from the end of each line to the beginning of each line...

   small biorhythm program illustrating interactive terminal operators
   (maybe with terminal graphics...ok, this is not a small program,
   but it could be patched together from perhaps three small
   programs), a small graphic library illustrating workspace name
   choices and given names, etc (all these just off the top of my
   head)...

Um... aren't graphics rather machine specific?  Also, aren't
biorhythms rather non-interactive?  [they just sit there.]

As for the workspace name stuff, this works rather well:

   lws=. list_workspaces=. 0!:0@('ls '&,@ (,&'/*.jws'))
   lwnms=. list_workspace_names=. 2!:1 @ <

Ok, so it's not very flashy.  However, the first will work on any unix
machine, while the second will work on anything [that supports J, that
is].

Point taken, though.  Maybe I'll try and post some interface code.
[However, there's nothing magic about me -- you can post too, you
know.]


+------------------
| Doug Evans
| <20@sspiff.UUCP> 18 Nov 91

In article <1991Nov14.045427.12325@yrloc.ipsa.reuter.COM>,
 hui@yrloc.ipsa.reuter.COM (Roger Hui) writes:
>
> ... stuff deleted
>
> b. If space were a problem, I could have appended each result to
> a file as it became available, i.e.
>    append&(<'outfile')@(,&lf)@sel;._2     instead of   <@sel;._2
>       or
>    append&(<'outfile')@;@:(,&lf&.>)@def   instead of   <@def
> or else used "iread" instead of "read".

Hmmm ... perhaps David was looking more for how to write filters
(a la grep, sed, awk, etc.) in J?

> c. Those interested in comparisons can solve the problem specified
> in the opening paragraph in their favorite APL dialect, C, Fortran,
> etc., then compare their solutions to the solution in this msg.

I offer the following for comparison:

1) grep '^#define' *.h ] awk -F'[ \t\(]+' '{ print $2 }' ] sort ] uniq
2) awk -F'[ \t\(]+' '/^#define/ { print $2 }' *.h ] sort ] uniq
        - an improvement of (1)
3) sed -n -e "/^#define/ s/^#define[ \t]*//p" *.h ] sed -e "s/[ \t(].*//" ] sort
 ] uniq

Unix one liners!    :-)
(NB: replace \t with tab character)
I'm sure others could come up with more and better ones (probably even
find bugs in the above ones!).

"Standard" programming languages (incl. J) aren't necessarily the only
solutions to some problems. ("Standard" here is meant to refer to those
languages one thinks of as programming languages).


+------------------
| Roger Hui
| <1991Nov19.011150.29495@yrloc.ipsa.reuter.COM>


David Feustel writes:

 I just typed in Roger Hui's examples and things don't quite work.
 It could well be that I made errors while typing in the definitions.
 An idea from HP48sx land came to mind: have the =. and =: operators
 print out a CRC of the definition so that the accuracy of the input
 can be checked easily.

As is customary, executable expressions in my post of 1991 11 14 4 54 27
were taken directly and automatically (not by retyping) from scripts and
session logs, and were tested again from the text of the news item.
(Both on J PC version 3.4.)  If problems persist after verifying that
they are not due to typing errors, we should resolve them by e-mail.
(Start by sending the text of the news item back to me.)

The solution to such problems is for the sender to exercise care
in composing the original text (which I have done), and for the
receipient to exercise care in transferring the text for execution.
Adding bells and whistles to language primitives is not the answer.


+------------------
| David Feustel
| <1991Nov19.211311.27484feustel@netcom.COM>

CRC checks make input verification a lot easier on the HP48sx. I'm not
sure how it can be fitted into J, but I recommend it.


+------------------
| Mark Keil
| <1991Nov20.055922.22395@apollo.hp.com>

In article <1991Nov19.211311.27484feustel@netcom.COM> feustel@netcom.COM (David
 Feustel) writes:
> CRC checks make input verification a lot easier on the HP48sx. I'm not
> sure how it can be fitted into J, but I recommend it.

You ought to be able to crate a verb (pro-verb?) for that.
Something that would act on the results of 3!:1 on the appropriate noun ...

This does bring up the interesting question of internal reprentation.
How does one grab ints without regard to the real underlying datatype?

Would it be necessary to use the linkj interface to do this kind of thing?

-Mark


+------------------
| David Feustel
| <1991Nov20.183040.7209feustel@netcom.COM>

The problem with not having an internal crc is that different people
will have different crcs and also that you can't use a crc to check code
being typed in that doesn't have a crc printed with it.


+------------------
| Robert Bernecky
| Date: 23 Nov 91

In article <1991Nov20.183040.7209feustel@netcom.COM> feustel@netcom.COM (David
 Feustel) writes:
>The problem with not having an internal crc is that different people
>will have different crcs and also that you can't use a crc to check code
>being typed in that doesn't have a crc printed with it.

Well, one simple approach to use is the following:

a. Write the CRC function of your choice. This is a good exercise in
   APL or J anyway.

b. Include the CRC function with your postings.

c. Include the result of applying the CRC to the "relevant part" of
   your posting as part of the posting. Perhaps even apply th CRC to
   itself?


+------------------
| David Feustel
| <1991Nov24.143333.22569feustel@netcom.COM>

rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:

>In article <1991Nov20.183040.7209feustel@netcom.COM> feustel@netcom.COM (David
 Feustel) writes:
>>The problem with not having an internal crc is that different people
>>will have different crcs and also that you can't use a crc to check code
>>being typed in that doesn't have a crc printed with it.

>Well, one simple approach to use is the following:

>a. Write the CRC function of your choice. This is a good exercise in
>   APL or J anyway.

>b. Include the CRC function with your postings.

>c. Include the result of applying the CRC to the "relevant part" of
>   your posting as part of the posting. Perhaps even apply th CRC to
>   itself?

>Bob


>Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca
>Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694
>18 Fifth Street, Ward's Island
>Toronto, Ontario M5J 2B9
>Canada

Thanks. This is a very good idea. I will definitely do this if I get
to the point that I think I have some useful J code to share.


 