                                   Chapter 1

                                   WHAT IS J


      J
      What J is
      A preliminary review of J
      First Impressions of J
      what is j?
      J?
      APL <-> J
      for Mr. Hui


*========================================
# J

+------------------
| L.J.Dickey
| <1990Aug26.125937.29181@water.waterloo.edu>

A new dialect of APL called "J" has been developed by Iverson Software
Incorporated and was announced at APL90.  At the show, versions of J
for the IBM PC and for the Mac were distributed free.  There are also
versions for the VAX, MIPS, and Next available.  These latter three
are presently available on a limited basis from me.

J is an advanced dialect of APL.  It has boxed arrays, operators
that accept user defined functions, (true) user defined operators, and
complex numbers.  It uses the ASCII character set.



*========================================
# What J is

+------------------
| L.J.Dickey
| <1990Nov8.144048.12624@aftermath.waterloo.edu>

In article <1990Nov7.150240.15740@cunixf.cc.columbia.edu> shenkin@cunixf.cc.
columbia.edu (Peter S. Shenkin) writes:
>
>I'm a new subscriber to this group;  [...]  and have
>come in in the middle of the discussion of J.  [...]
>  Can some kind soul either post or mail me a brief description of
>what J is, and how it relates to APL?

J is a dialect of APL that has boxed arrays, complex numbers,
user defined operators, and uses the ascii character set.

It runs on several systems, and the code is intended to be easily
portable from one system to another.

Here is a little bit of code that might begin to show some of the
similarites and some of the changes in J.

   stuff =. 'abcdABCD'
   $ stuff
8
   stuff i. 'aA'
0 4
   n =. i. $stuff
   sum =. +/
   sum n
28
   n sum n
0 1 2  3  4  5  6  7
1 2 3  4  5  6  7  8
2 3 4  5  6  7  8  9
3 4 5  6  7  8  9 10
4 5 6  7  8  9 10 11
5 6 7  8  9 10 11 12
6 7 8  9 10 11 12 13
7 8 9 10 11 12 13 14
   i. 2 3
0 1 2
3 4 5



*========================================
# A preliminary review of J

+------------------
| Raul Rockwell
| <12061@chaph.usc.edu> 20 Sep 90 10:55:05 GMT

[[ NB. sws.  I've just edited this to work under 4.1 ]]

J is a fairly recent dialect of APL, greatly simplified in several
respects, and significantly enhanced in some others.  It includes
improvements slated for inclusion in APL dating, in some cases, all
the way back to the 60's.

I've been playing with version 2, which is not quite complete, and has
a clunky user interface, but I've been quite impressed.

If you're not interested, hit 'N' now.



J as a functional language (e.g. along the lines of scheme):

J has 0 keywords, and will take arguments from both sides of a
function, but if you don't mind the restriction, you can make it look
remarkably like scheme:

   o    =. 0 0$''                   NB.' "nothing" -- very useful :-)'

   read =. 1!:1                     NB.' associate name with system call'

   set  =. (read 1) : ''            NB.' scheme-like set'
(y. , '=: y.') : ''                 NB.' function which assigns data to name'

   indirect =. (read 1) : ''        NB.' converts 2 arg fns into a 1 arg form'
(y. , '&  y.') : ''

   plus =. indirect '+'
   first=. indirect '{.'
   rest =. indirect '}.'

   o NB.'     use of the above definitions:'

   ((set 'foo') 1 2 3 4 5)
1 2 3 4 5

   (first foo)
1

   (rest foo)
2 3 4 5

   ((plus 8) foo)
9 10 11 12 13

[[NB. sws.  the above two definitions won't work anymore. This is
  NB. because verbs can no longer return verbs. The closest I've
  NB. come is:

   set  =. (read 1) : 2          NB. scheme-like set
(y. , '=: y.') : ''              NB. function which assigns data to name

   indirect =. (read 1) : 2      NB. converts 2 arg fns into a 1 arg form
(y. , '&  y.') : 2

   plus =. '' indirect '+'
   first=. {.
   rest =. }.

   o NB.'     use of the above definitions:'

   (('' set 'foo') 1 2 3 4 5)
1 2 3 4 5

   (first foo)
1

   (rest foo)
2 3 4 5

   (('' plus 8) foo)
9 10 11 12 13

]]

Their are, of course, a number of differences between J and scheme.
For example, if you wanted a structure more complicated than a simple
list of numbers or list of characters, you would need to use one of
J's structure building functions:

   (rest 'foo';'bar';'bletch')
+---+------+
|bar|bletch|
+---+------+

The boxes indicate that the enclosed lists (of characters) are being
treated as scalars.  The semicolons indicated that I wanted the
strings boxed and linked together in a list.

The parser is, well, very minimalist--roughly equivalent to LL(4)--and
available as a primitive function.  Evaluation and parsing are
synonymous.  (The lexical analyzer is also extremely simple, and
available as a primitive function.)  Also, for those of you not
familiar with apl, the parser runs right to left instead of left to
right.

J words fall into one of 6 syntactic classes:

Punctuation (left and right parenthesis)
Copulae (local assignment and global assignment)
Adverbs and Conjunctions (roughly equivalent to declarations)
[imperative] Verbs (functions)
Nouns (data)

Adverbs are distinct from conjunctions because they have different
syntax.  Primitive adverbs and conjunctions all appear to yield
verbs as their result.  Primitive functions all yield nouns.

Names can be assigned any type of word, except punctuation.  For example:

   test =. /
   a    =. +
   is   =. =.
   this is a test
   this 1 2
3

'test' became an adverb, 'a' became a verb, and 'is' became a copula.
'this is a test' assigned to 'this' the derived verb '+/' which has
the effect of placing the function '+' between each of the array cells
of its argument.

[[ NB. sws.  you can no longer simply use asignment for =.. Here's
   NB. something similar:

   test =. /
   a    =. +
   is =. (read 1) :2
(x.,'=:y.f.') :2
 ''  ('this' is '')(a test)
   this 1 2
3
]]

J differs from most other dialects of APL in a number of ways.  J is,
for example, statically scoped.

Also, it has 'phrasal forms' where several functions can be combined
to form a single function.  For example:

   3 (+,-,*,%) 2
5 1 6 1.5

Note that '*' means multiplication, and '%' means division.  If you
ask J to evaluate something which evaluates to a function, it will
show you the tree structure it uses to represent that function:

   +,-,*,%
+-+-+-------------+
|+|,|+-+-+-------+|
| | ||-|,|+-+-+-+||
| | || | ||*|,|%|||
| | || | |+-+-+-+||
| | |+-+-+-------+|
+-+-+-------------+

(That looks a lot better if you use the pc's line drawing
characters... oh well..)

Basically, in a phrasal form, like the above, the left and right
arguments to the derived function go to each the 'odd' functions, and
the results of those functions go to the 'even' functions.  So the
above example is equivalent to:

   (3+2),(3-2),(3*2),(3%2)
and yields the same result:
5 1 6 1.5

I haven't seen anything like this in any other computer language, so
it should look quite foreign to most of you.  I suppose the point I'm
trying to get across is that J allows an extremely wide range of
expressiveness.  Enough that style becomes MUCH more important than
substance...

J is supposed to be available in a freely redistributable form for
PCs, Macs, NeXT machines, MIPS, VAX, and a handful of others (e.g.
sun3 and sun4.. but that particular version is still vapor).

Check with the comp.lang.apl newsgroup for specifics of what versions
are available, and from where.  I know the pc and mac versions are
available for anonymous ftp from watserv1.waterloo.edu.

Documentation, at present, is pretty skimpy.  There is supposed to be
a book available, but I haven't received my copy yet.  The best I can
recomend is print out all the text files that come with the
distribution, and try the examples.  Documentation on APL, and past
issues of ACM's SIGAPL journal (Quote Quad -- look for anything
written by Ken Iverson.  I think volume 18, No. 1 is probably the best
mine of information) can give you some hints.

If there is enough interest, and if I can access the net, I'll post
more, later.


Oh yeah, by the way, if you use the 'read' function I defined towards
the begining of this post, and you want to read multiple lines, the
notation is:
   read 1 1 1
to read 3 lines.  You can make this more stylistic by defining a sort
of a bastardized adverb ('bastardized', because it is meant to return
a noun, not a verb) as follows:

   lines=. (read 1) :1
x. $ 1

This allows you to say:
   read 3 lines
instead of (read 1 1 1)



*========================================
# First Impressions of J

+------------------
| John Baker
| <90289.112513BAKERJ@QUCDN.QueensU.CA> 16 Oct 1990 11:25:13 EDT


In the last week I have been experimenting with J version 2.3
from Iverson Software.  So far I am impressed.  J is remarkably
complete (the documentation indicates what remains to be done).
implementation of "pure" rationalized APL.

A few brief observations.

     1)  It's amazing how fast you get used to the use of ASCII.
         J's ASCII symbols are well chosen.  The language has
         has a nice look to it and it's easiar to type and
         print than convential APL. I appreciate
         the APL character set but languages like J and Nial
         have convinced me that it is not necessary.

     2)  As a language J rigorously implements the extended
         Iverson notation first discussed in Rationalized
         APL back in the early 80's.  J has taken a number
         of much needed steps.  Standard line number based
         function definition has been thankfully trashed.
         Syntactic constructs that don't fit into the
         rational scheme (ie index brackets) have been
         eliminated. Verbs (functions) in old Sharp APL that had
         inappropriate function ranks have been fixed.
         Many new verbs, adverbs and conjunctions have
         been added.  J is certainly powerful.  It's well beyond old
         pre-nested array APL's.  It's in the same class as
         APL2 and Nial.

     4)  The ISI interpreter written by Roger Hui has not
         implemented workspaces.  He has adapted an ASCII
         script scheme that is certainly sufficient for
         for demonsration software. I've been impressed
         with the performance of the interpreter and it's
         scope.  This is the only $24.00 package I [k]now of
         that computes complex matrix inverses.

[[ NB. sws.  this has changed, ws are available. LINPACK has always
   been free... and now we have LAPACK for matrix inverse.
 ]]

     5)  Overall ISI's J is an amazing bargin.  For $24.00
         you get the J interpreter.  Iverson's paper (ISI J Dictionary),
         and a little booklet called -- Tangible Math.
         I have a feeling that J is going to attract
         a lot of interest within and,  to a lesser degree,
         outside of the APL world.   Who knows it may even
         revitialize this inbreed little corner of computerdom.



*========================================
# what is j?

+------------------
| Greg Trice
| <199113.993.337@canrem.uucp> 13 May 91 12:32:05 EST

  I've only recently started to read this group, and I'm mystified by
all the references to J. I assume it is a language, if so, what
relationship does it have to APL? I've used APL for many years and I've
never seen any other language that remotely resembled it. Is J such an
animal? Perhaps for the benefit of those new to J somebody could post a
listing showing where APL and J differ. I'm assuming J has some
relationship to APL because why would it be discussed here otherwise?


+------------------
| L.J.Dickey
| <1991May14.115924.2017@watmath.waterloo.edu>

In article <199113.993.337@canrem.uucp> "greg trice"
>   <greg.trice@canrem.uucp> writes:
>  I've only recently started to read this group, and I'm mystified by
>all the references to J. I assume it is a language, if so, what
>relationship does it have to APL? I've used APL for many years and I've
>never seen any other language that remotely resembled it. Is J such an
>animal? Perhaps for the benefit of those new to J somebody could post a
>listing showing where APL and J differ. I'm assuming J has some
>relationship to APL because why would it be discussed here otherwise?

J is a dialect of APL.  Its special features include boxed arrays,
complex numbers, the rank operator, other new operators, hook and
fork, and tacit function definition.  Its closest linguistic relative
is SAX APL ( Sharp APL for UNIX ).   It runs on several machines,
including Mac, PC, Atari ST, Archimedes, SUN, MIPS, VAX (BSD), SGI,
and NeXT.  The code is easily portable, because it is fully ascii
text.  The software is free to those who have net or BBS access.

It is currently being developed by Iverson Software Incorporated
(yes, the same Iverson who invented APL).

Some interesting examples of J code are:

           data =. 10 + i. 6
           data
        10 11 12 13 14 15
           sum =. +/
           sum data
        75
           $ data
        6
           avg =. sum % $
           avg data
        12.5

You can learn a lot about J from this example.
Index origin is always 0.
Tacitly defined verbs (such as "sum" and "avg"), don't mention the
argument.

The function "avg" above is an example of a fork.  The fork comes
in two flavors, monadic and dyadic. The monadic fork
        (f g h) y
means
        (f y) g (h y)
and the dyadic fork
        x (f g h) y
means
        (x f y) g (x h y)
.  A model that I keep in my head for the dyadic fork can be
illustrated by the "lessthan or equal" idea, which this example
shows:

           or =.   +.
           1 0 1 0 or 1 1 0 0
        1 1 1 0

           5 < i. 10
        0 0 0 0 0 0 1 1 1 1
           5 = i. 10
        0 0 0 0 0 1 0 0 0 0
           5 ( < or = ) i. 10
        0 0 0 0 0 1 1 1 1 1

Yes, of course, J does have a "lessthan or equal" verb of its own,
so the above particular lines probably would not be used in any
application.  It is just that this example shows how natural the
fork is, and how close it is to common usage.  It is surprising
to me that it has not been introduced into programming languages
before.


+------------------
| Raul Rockwell
| <ROCKWELL.91May14072750@socrates.umd.edu>

Greg Trice:
     I've only recently started to read this group, and I'm mystified
   by all the references to J. I assume it is a language, if so, what
   relationship does it have to APL? I've used APL for many years and
   I've never seen any other language that remotely resembled it. Is J
   such an animal? Perhaps for the benefit of those new to J somebody
   could post a listing showing where APL and J differ. I'm assuming J
   has some relationship to APL because why would it be discussed here
   otherwise?

:-)

Well, it might help if I pointed out that Ken Iverson (and others)
designed J.  If you want more information, note that J is distributed
by Iverson Software, Inc.
   33 Major Street
   Toronto, Ontario
   M5S 2K9

Or, on the net, you can check out
   watserv1.waterloo.edu:languages/apl/j

The most noticeable differences between J and APL are:
   J uses ascii, rather than the APL character set
   J assignment is more powerful than APL
   J has a number of operators and functions which (as a general rule)
     are not present in APL.

I believe one way of describing the differences is to say that J is a
dialect of APL.  (If you're familiar with I.P. Sharp APL, J is closer
to that than, say APL2).

However,
   +/1 2 3
6
in both languages.

Perhaps a better example of the differences is iota and reshape.  In
APL,  iota 5 gives either
1 2 3 4 5
or
0 1 2 3 4

In J, iota is replaces with 'i.', and  i. 5 yields
0 1 2 3 4

In APL, 2 rho 3 2 rho iota 6 (I'm going to assume quadIO is 0) yields:
0 1


In J, reshape is indicated by $, and  2 $ 3 2 $ i. 6 yields
0 1
2 3

but   2 $, 3 2 $, i.6   yields
0 1

($ reshapes along the first dimension, and you must ravel higher
ranked arrays if you want exactly the same behavior as APL).


There are lots more differences (for instance, J uses assignment to
generate functions, rather than the del editor), but the best way to
find out what they are is plunk down 24 dollars and get a copy of the
current version of the language (and the documentation), then work
your way through the tutorials.  (Or ftp to watserv1, but you don't
get much in the way of docs from there :-(



*========================================
# J?

+------------------
| Raul Rockwell
| <16MAR91.22251826@uc780.umd.edu>

David Feustel:
>I'm new. What's J? Is source available? What machines and OS's does it
>run under? Thanks.

Hi,

This may be restating the obvious, but J is a programming language.
It is, I think, more than a little elegant.  The current incarnation
is probably what you'd call a beta-version.  It's not quite fully
implemented, and could stand some real speed improvements.  (It is,
however, infinitely faster than vaporware.)

Source, sadly, is not available.  Though if the GNU people get rich
enough the Iverson Software people may follow in their footsteps.
(Iverson Software Inc. is the group writing/providing the
interpreter.)

[[NB. sws.  source is now available!!]]

As for what machines it runs on, memory tells me pcs, sun4s,
bsd-vaxen, mips machines, and I believe next machines and macs, and
probably others.  Ftp 129.97.129.140 (I think that's
watserv1.waterloo.edu), /languages/apl/j ... subdirectory by
architecture, for binaries.  If other machines than these are
supported, I'm sure the ISI people will be happy to tell you.

Slight problem... there isn't much in the way of on-line docs for J.
I'm not sure how such docs fit in with ISIs philosophy...  Currently,
if you send them $24, they'll send you docs and a copy of their latest
version of the software...  If you can tolerate dense information, the
binaries come with a complete list of commands (indicating what's
implemented), and detailed docs on each of the system commands.  There
are also about 40 screens worth of example code, grouped by subject.
There's also a little custom previewer to look at the example code.

Following is a quicky example (something I was playing with earlier
today).  I didn't write it for anyone else, so it has only one
(useless) comment, but I'll try and add some docs at the end.

Example (uuencode) follows...

$ j
J Version 2.9   Copyright (c) 1990 1991, Iverson Software Inc.

   2!:4 <'uu.jws'
1
   uul
+---------+--+----------------------------------------------------+
|(#y.)$:y.|::|uunum =. #. ((4 * >. x. % 3),6) $, (8#2) #: a. i. y.|
|         |  |   a. {~ (32 + x. , uunum), 10                      |
+---------+--+----------------------------------------------------+
   uul 'foobar'
&9F|O8F%R

   uuenc
+--------------+--+-------------------------------------------------+
|'644 file'$:y.|::|nl=.    10 { a.                                  |
|              |  |'mn'=.  0 45 #: # y.                             |
|              |  |begin=. nl,'begin ',x.,nl                        |
|              |  |end=.   (uul ''),'end',nl   }: 'requires uul'    |
|              |  |   begin, (,uul"1 (m,45)$y.), (uul (-n){.y.), end|
+--------------+--+-------------------------------------------------+
   uuenc 'This is a test, This is only a test.  If it weren''t a test.....'

begin 644 file
M5&AI<R!I<R!A('1E<W0L(%1H:7,@:7,@;VYL>2!A('1E<W0N("!)9B!I="!W
297)E;B=T(&$@=&5S="XN+BXN

end

[[NB. sws. Try this:

   dyad=. 'uunum =. #. ((4 * >. x. % 3),6) $, (8#2) #: a. i. y.'
   dyad=. dyad; 'a. {~ (32 + x. , uunum), 10'
   uul=. '(#y.) uul y.' : dyad
   uul
+------------+-+----------------------------------------------------+
|(#y.) uul y.|:|uunum =. #. ((4 * >. x. % 3),6) $, (8#2) #: a. i. y.|
|            | |a. {~ (32 + x. , uunum), 10                         |
+------------+-+----------------------------------------------------+

   uul 'foobar'
&9F]O8F%R

   dyad=. 'nl=. 10 { a.'
   dyad=. dyad; '''mn''=.  0 45 #: # y.'
   dyad=. dyad,< 'begin=. nl,''begin '',x.,nl'
   dyad=. dyad,< 'end=.   (uul ''''),''end'',nl   [ ''requires uul'''
   dyad=. dyad,< 'begin, (,uul"1 (m,45)$y.), (uul (-n){.y.), end'
   uuenc=. '''644 file'' uuenc y.' : dyad

   uuenc
+-------------------+-+----------------------------------------------+
|'644 file' uuenc y.|:|nl=. 10 { a.                                  |
|                   | |'mn'=.  0 45 #: # y.                          |
|                   | |begin=. nl,'begin ',x.,nl                     |
|                   | |end=.   (uul ''),'end',nl   [ 'requires uul'  |
|                   | |begin, (,uul"1 (m,45)$y.), (uul (-n){.y.), end|
+-------------------+-+----------------------------------------------+

   uuenc 'This is a test, This is only a test.  If it weren''t a test.....'

begin 644 file
M5&AI<R!I<R!A('1E<W0L(%1H:7,@:7,@;VYL>2!A('1E<W0N("!)9B!I="!W
297)E;B=T(&$@=&5S="XN+BXN

end

]]

(Incidentally, I hope you have a way of splitting your screen to read
this, otherwise I guess you'd have to print it out...)

First, programs name is 'j', you get that banner every time you start,
and the default prompt is three spaces.

Second, that 2!:4 is a raw system call.  Library 2 is workspaces (J
will allow you to manage objects on file by name, if you'd rather that
than raw character data).  Call 4 happens to be a read command.  The
file I wanted to load was called uu.jws, and since the call needs a
pointer to a string, < makes one (kind of like * in c).  The 1 is a
return code indicating success.

Most people consider this sort of thing gory, and make themselves a
profile file to provide nice covers for system calls and such.  I
don't bother, because I've been using J on a guest account, and
everything gets blown away every few days.

The routine 'uul' takes a line of up to 45 characters and returns the
corresponding line of uuencoded garbage.  Quick summary:

        ::  says this is a verb (function).  The string on the left is
the verb's intransitive form (takes only one argument).  The string on
the right is the verb's transitive form (takes two arguments).

        $: is a self reference (by the verb, to itself).  Normally,
it's used for recursion, here I was playing around with the idea
uuencode, and thought I might want to claim that a string had some
length different from what it really had.  So the transitive form
takes a left argument of the strings 'intended' length.

        y. is the right argument to the verb.  In the transitive case,
x. is the left argument.

        # counts how many elements are in a list (or string) when used
intransitively, and if used transitively the left argument says how
many copies to make.

        a.i.y. converts an ascii string into numeric form.  (a. is the
ascii character set, with ascii character 0 in position 0, ascii
character 1 in position 1, etc.)  i. looks up each character and
returns the indices (which are the ascii codes).

        #: converts from number to a list of digits which represent
that number.  The eight 2's mean I get 8 bits (base 2 digits) for each
number.

        The , (used intransitively) means ignore the structure of the
array that #: generated.  This is important because $ (used
transitively) gives it a new shape:  Instead of 8 columns, it will now
have 6, and to make up for than, I increase the number of rows by a
third.

        % is division, so x. % 3 is one third the original length.  >.
raises that value to the next highest integer (if it's fractional).
4 * ... multiplies by four.

        #. converts from the base two representation back to a list of
numbers.  These numbers each will be encoded as characters on the next
line.

        =. is an assignment statement.  It localizes the name on the
left too.

        On the next line, (,) is used transitively to catenate the
number of characters represented onto the beginning of the line.  Then
all these numbers are offset by 32, to avoid control characters.  A 10
is added onto the end (ascii 10 is newline).  Then the numbers are
converted to ascii.

        a.{~y  is roughly equivalent to the C statement a[y], except
that it works on all the data you specify.  Thus, a.{~ 102 111 111
would return the three character string 'foo'.  (By the way, ~ means
swap the arguments (give the right argument on the left, and the left
argument on the right)  102 111 111 { a.  would also yield 'foo'.)

        The last line executed in a verb gives that verb's return
value.  It is unfortunate, I suppose, that you can't tell from the
display that the intransitive form of uul has only a single line.

        Still with me?  I suppose it should be apparent by now that a
single line in J will often hold as much meaning as a full screen of
text in a number of other languages.  It would be a mistake to try and
read over J by simply glancing at a page and expecting to get the gist
of what's going on in a couple seconds.  Or, not at first at least.

        If you can get used to reading one line as carefully as you
would a number of lines in lisp, or modula, or whatever, you should
find that it is just as understandable.  Of course, it's alway handy
to have a computer at hand to see what each part of a statement does
to representative data.

        I tried a short example of uul, not to attempt to show how it
functions (to do that, you'd want to do something a bit more
step-by-step), but to compare with the results of uuencode.  The
garbage looked the same, so I wrote a cover to handle the larger parts
of the uuencode format.

        The intransitive form of uuenc is very similar to the
intransitive form of uul:  In this case I'm providing a default header
(file access privileges, filename) argument so I don't have to worry
about that for testing.

        First, since I was using more than one instance of the newline
character, I stuffed that into a variable.

        Second, since uuencode puts out 45 characters per line (except
for the last line), I convert the number of characters in the argument
string to a two digit 'base 45' number.  (Well, sort of.. that leading
0 means the leading digit can be as large as necessary to hold the
result, it is not cut off arbitrarily at 44).  The string 'mn' that I
assign into means variable m gets the first number (the number of
whole lines to be converted), and the variable n gets the last number
(the length of the last, partial length line).  J uses two quotes when
quoting variables, instead of a single quote (like lisp does), and
allows a shortcut (which I use here) when using variables with single
character names.  If I wanted to be really formal, I would have
written:     ('m';'n') =.  0 45 #: # y.    Or, I could have gone
further and computed the quotient on one line, and the remainder on
another.

        Incidentally, it just occurred to me to wonder if uudecode
will choke if there are two terminating lines (nl,' ',nl,' ') between
the last line of garbage and the 'end' string.  I don't think it will,
but feel free to test for that condition.

        Ok, the third line of uuenc constructs the header.  Nothing
really but simple string catenation.

        The fourth line constructs the ending sequence.  uul applied
to an empty string simply returns a space and a newline, but I was
feeling a touch formal when I wrote this.  If it turns out that
uudecode chokes with two blank lines at then end, I'd throw a test in
here to get rid of the space,newline when it isn't needed.

        Finally, I put all the pieces together and return that as the
function result.  Starting in the middle,  (m,45)$y.  converts the
argument string into a table of characters where each row is 45
characters long.  Usually this table is slightly smaller than the
original string and a few characters get dropped off the end.

        uul"1 means that I am passing to uul individual strings (i.e.
one dimensional arrays).  J automatically executes uul once for every
row, and puts together the result into a single array.  After that, I
use the intransitive (,) (called ravel) to throw away all the details
of the array.  After all, my result is intended to be just a string.

        (-n) {. y.   grabs whatever would get left out of that big
array and runs it through uul separately.  I think this is important,
because the manual pages on uuencode didn't seem to permit a lot of
padding at the end, at least not before the end marker.

        To test this out, I ran a few strings through uuenc, stuffed
them out to file, and then ran uudecode on them.  The basic concept
looks good (no bit-reversal problems or anything like that).

        I think this is an order of magnitude slower than uuencode,
but it is at least somewhat educational.

        And, who knows, maybe with future versions of the interpreter
speed for things like this will increase drastically.  (Not entirely
an unreasonable idea.  I found that on a 16Mhz 386, with a version of
J from last October, I was getting about 2 milliseconds per integer
addition (that's trying things like  x + y  where x and y each had a
thousand integers in them).  Like I said earlier, quite a bit faster
than vaporware.  But still well below what I expect the performance
ceiling to be.

        uuenc, on a rather loaded sun4, generally took what seemed
like a couple seconds to run through a 5 lines message.  Of course I
didn't actually time it, and I was experiencing some pretty heavy-duty
transmission lags (around a second or two between hit return and see
response for just about everything), but that's internet for you.

P.S.  This has gotten long, sorry about that.


+------------------
| Raul Rockwell
| <16MAR91.23163344@uc780.umd.edu>

I just re-read my last post.  It has an embarrasingly large number of
typos (I knew I should've proofread it before I posted...).

If the language is too muddy for anyone, write me.  I'll email a
clarification.  If I get many queries, I'll post too.



*========================================
# APL <-> J

+------------------
| Sam Sirlin
| <1991Jan18.165603.18529@jato.jpl.nasa.gov>

In article <15160014@hpdmd48.boi.hp.com>, rrr@hpdmd48.boi.hp.com (Rudi Rynders)
writes:
]>

..

]>  As for my suggestion of a text comparing APL and J: I still
]>  think it would be a good idea to have one to make the path to "J"
]>  a bit less thorny. The chances of "J" becoming popular will be a
]>  lot better with it than without it IMHO.

I agree. From my own impressions, and correspondence here and on BBS\APL,
even APLers have trouble with J. While some of this is undoubtedly our
expectations (we're used to our symbol set), APLers must start out to be
pretty tollerant of new symbol systems even to use APL. My guess is that
BASIC or FORTRAN people will have much more trouble with J.

Be that as it may, there's also alot of APL software written already
(EISPACK, ODE solvers, controls analysis, graphics). If I start using J
seriously, I don't want to write all my software over again, hence I'll
(eventually) work on an APL -> J translator, probably in STSC APL. Right
now, the hardest part of this seems like dealing with indexing, but I
think I can do this.



*========================================
# for Mr. Hui

+------------------
| W. Felscher
| <9105211421.AA10695@mailserv.zdv.uni-tuebingen..de> 21 May 91

Dear Mr. Hui,

1. yes, I would like to use J on an RS6000

2. I tried to send this to hui@yrlok.ipsa.reuter.com, but
   only got as far as itcyyz.ipsa.reuter.com (5.59/smail2.5/11-23-89)
   from where there arrived the reply

          bad system name: yrlok
          uux failed. code 68
          550 <yrlok!hui>... Host unknown

3. So I repeat a question which I had intended not ask  over
   the net. I have asked it previously, with respect to APL,
   to some colleagues at IBM without receiving a
   satisfactory answer. Maybe in the case of J, which is
   just being build, the situation is more perspicuous:

   Is - or will there ever be - documentation on the runtime
   (in assembler we would count the number of tacts) which
   a particular construction or command requires ? Or is the
   dynamic behaviour, in particular buffer allocation, so difficult
   to predict that no such information can reasonably be
   expected ?

   The background to this question is, of course, the
   teaching of languages such as APL or J to students. It
   then seems impossibile to make theoretical comparitions
   between the complexities of different algorithms (which
   a certain part of theoretical CS is concerned with).
   On the contrary, it appears that in APL every knowledge comes
   from practical experience with particular implementations.
   And this then leads to programming constructions which,
   by the average user, can't be justified theoretically
   but only by experiencing that they happen to work
   well. It IS very satisfactory to have such powerful
   instruments as APL and J are - but one would like to know
   more about how to 'program' it.


 