                                   Chapter 9

                            USING J : OTHER FUNCTIONS


      J and nested vectors
      Determinant
      Basic Questions About J


*========================================
# J and nested vectors

+------------------
| Ken Block
| <27567@uflorida.cis.ufl.EDU> 22 Mar 91

I am under the impression that J does not have nested vectors.
Is this true?

How could I do something like the following apl:

x function foreach ((1 2 3) (5 6 7) (1 2 5) (2 3 4))


+------------------
| Raul Rockwell
| <22MAR91.00311616@uc780.umd.edu>

Since no responses have reached my site yet, I guess I'll field this one...

Ken Block writes:
>I am under the impression that J does not have nested vectors.
>Is this true?

Not really

>How could I do something like the following apl:
>x function foreach ((1 2 3) (5 6 7) (1 2 5) (2 3 4))

The function part might be written as   f &. >   if you wanted to
deal with it as a nested array.  Note that you could also convert that
thing to a matrix, and use   f " 1   with no loss in information or
functionality.

&.   by the way means "use the function on the right as a
pre-processor (and it's inverse as a post-processor) for the function
on the left."  The granularity is determined by the granularity of the
"function on the right".  So (f) would get evaluated once for the
array 1 2 3, another time for the array 5 6 7, and so on.

"   means simply, apply the function (on the left) using on arrays of
rank n (the number on the right).  So you get a foreach type operation
that's useful on regular arrays.

To construct the nested array, you could write:
   1 2 3; 5 6 7; 1 2 5; 2 3 4

Grab a copy of J and try it out.  Personally, I prefer answering
questions of people who are stuck than I do people who've never even
gotten that far.


+------------------
| L.J.Dickey
| <1991Mar22.140620.3809@watmath.waterloo.edu>

In article <27567@uflorida.cis.ufl.EDU> krb@uflorida.cis.ufl.EDU (Ken Block) writes:
>I am under the impression that J does not have nested vectors.
>Is this true?

J has "boxed" vectors.  The idea is similar, but with box, (given by "<"),
scalars are not a special case, as with nested arrays.

Here is a session script:

   sum =. +/
   avg =. sum % #
   data =. 1 2 3; 5 6 7; 1 2 5; 2 3 4 5 6
   data
+-----+-----+-----+---------+
|1 2 3|5 6 7|1 2 5|2 3 4 5 6|
+-----+-----+-----+---------+
   sum &. > data
+-+--+-+--+
|6|18|8|20|
+-+--+-+--+
   avg &. > data
+-+-+-------+-+
|2|6|2.66667|4|
+-+-+-------+-+

   n234 =. 100 200 +/ 10 20 30 +/ 1 2 3 4
   n234
111 112 113 114
121 122 123 124
131 132 133 134

211 212 213 214
221 222 223 224
231 232 233 234


   sum n234
322 324 326 328
342 344 346 348
362 364 366 368
   avg n234
161 162 163 164
171 172 173 174
181 182 183 184


   sum "1 n234
450 490 530
850 890 930
   avg "1 n234
112.5 122.5 132.5
212.5 222.5 232.5


   sum "2 n234
363 366 369 372
663 666 669 672
   avg "2 n234
121 122 123 124
221 222 223 224


I hope this helps.


+------------------
| Michael J. A. Berry
| <MJAB.91Mar22151853@nanna.think.com>

In a posting, you asked:

   How could I do something like the following apl:

   x function foreach ((1 2 3) (5 6 7) (1 2 5) (2 3 4))

The straightforward answer is by defining a foreach operator like so:

   foreach =. &.>
   foo foreach  1 2 3; 5 6 7; 1 2 5; 2 3 4

However, J has several more interesting ways of partitioning data which
make the use of boxed arrays less pervasive than in APL2 (which I assume is
the dialect of APL you quote in your example.

In particular, the rank operator lets you apply functions to cells of any
rank within a higher rank array.  In your example:

   foo"1 (4 3$ 1 2 3 5 6 7 1 2 5 2 3 4)

Even more interesting to my way of thinking is partitioning by keys as in:

   text
the quick brown fox jumped over the lazy dog
   Vowel =. e.&'aeiouAEIOU'
   Vowel text
0 0 1 0 0 1 1 0 0 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 1 0 0 1 0 1 0 0 0 0 1 0 0 1 0 0
0 0 1 0

   (Vowel text) </. text
+--------------------------------+------------+
|th qck brwn fx jmpd vr th lzy dg|euiooueoeeao|
+--------------------------------+------------+
   (Vowel text) $/. text
32
12

Here is an example of Quicksort implemented using /. and boolean keys:


   Qsort
+-------------------------------------------------------------------+--++
|$. =. > (Sorted y.){ recurse;return                                |::||
|recurse) $. =. (Any mask =. y. > Pivot  y.) }. recurse             |  ||
|         y. =. ,. (Collapse mask) { mask $:COLLECTING  y=: y.      |  ||
|return)  y.                                                        |  ||
+-------------------------------------------------------------------+--++
   Sorted
+-------------------------+--++
|*./ (1}. y.) >: (_1}. y.)|::||
+-------------------------+--++
   Any
+--+-+
|+.|/|
+--+-+
   Pivot
+------------+--++
|(''$?$y.){y.|::||
+------------+--++
   Collapse
+-----+--++
|~. y.|::||
+-----+--++
   COLLECTING
+-+--+-------+
|1|::|<&x. /.|
+-+--+-------+
   Qsort 20?20
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

[by the way the definition of Collapse is because I can't type the J for it
-- to my system that means hang up the phone!]

--
[[NB. sws. Now we have some minor spelling changes:
   m=. '$. =. > (Sorted y.){ recurse;return'
   m=. m; 'recurse) $. =. (Any mask =. y. > Pivot  y.) }. recurse'
   m=. m, <'y. =. ; (Collapse mask) { mask (Qsort COLLECTING)  y=: y.'
   m=. m, <'return) y.'
   Qsort=. m : ''
   Qsort
+---------------------------------------------------------+-++
|$. =. > (Sorted y.){ recurse;return                      |:||
|recurse) $. =. (Any mask =. y. > Pivot  y.) }. recurse   | ||
|y. =. ; (Collapse mask) { mask (Qsort COLLECTING)  y=: y.| ||
|return) y.                                               | ||
+---------------------------------------------------------+-++

   Sorted=. '*./ (1}. y.) >: (_1}. y.)' : 11
   Any=. +./
   Pivot=. '(''''$?$y.){y.' : ''
   Collapse=. '~. y.' : ''
   COLLECTING=. '<&x.f. /.' : 1

   Qsort 20?20
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

]]



*========================================
# Determinant

+------------------
| Roger Hui
| <1991May19.053021.7840@yrloc.ipsa.reuter.COM>

The determinant has been implemented in J this week.  The determinant has
rank 2 (applies to matrices), and is recursively defined by expansion
by minors along column 0:

   f . g y   is   (0{"1 y) f . g  f . g minors0 y  if 0<#y
                  identity element of g            if 0=#y

The dyad  f . g  plays a key role in this definition, thus motivating the
choice of the monad  f . g  to denote the determinant.  -/ . *  is the
ordinary determinant.

The verb minors0 computes the minors of a matrix along column 0.  Its
derivation is an interesting story.  It was originally defined using
complementary indexing:

   i0 =. <&.>&.> @ { @ (;&0) @ i. @ #
   minors0 =. i0 { [

   m =. 4 4$'abcdefghijklmnop'
   m
abcd
efgh
ijkl
mnop
   i0 m
+---------+---------+---------+---------+
|+---+---+|+---+---+|+---+---+|+---+---+|
||+-+|+-+|||+-+|+-+|||+-+|+-+|||+-+|+-+||
|||0|||0|||||1|||0|||||2|||0|||||3|||0|||
||+-+|+-+|||+-+|+-+|||+-+|+-+|||+-+|+-+||
|+---+---+|+---+---+|+---+---+|+---+---+|
+---------+---------+---------+---------+
    minors0 m
fgh
jkl
nop

bcd
jkl
nop

bcd
fgh
nop

bcd
fgh
jkl
   $minors0 m
4 3 3

Subsequently, Eugene McDonnell proposed the following alternative:

   ind =. -."1 0~ @ i. @ #
   drop0 =. }."1
   minors0a =. ind { drop0

The right tine of minors0a drops the first element of each vector (that is,
drops the first column of the matrix), and the left tine is a matrix where
successive rows successively exclude one index.  For example:

   ind m
1 2 3
0 2 3
0 1 3
0 1 2
   drop0 m
bcd
fgh
jkl
nop
   (minors0a m) -: minors0 m
1

Ken Iverson suggested yet another alternative.  The phrase x f\.y applies
f to outfixes of y obtained by suppressing successive infixes of size x.
For present purposes, we use the verb "same" ([).  Thus:

   f =. 1 & ([\.)
   minors0b =. drop0 @ f
   f m
efgh
ijkl
mnop

abcd
ijkl
mnop

abcd
efgh
mnop

abcd
efgh
ijkl
   (minors0b m) -: minors0 m
1

Moreover, this technique can be used to compute the major minors (i.e.
minors of size one less than the size of the matrix), an immediate
precursor to the classical adjoint:

   box =. <"2
   box minors m
+---+---+---+---+
|fgh|egh|efh|efg|
|jkl|ikl|ijl|ijk|
|nop|mop|mnp|mno|
+---+---+---+---+
|bcd|acd|abd|abc|
|jkl|ikl|ijl|ijk|
|nop|mop|mnp|mno|
+---+---+---+---+
|bcd|acd|abd|abc|
|fgh|egh|efh|efg|
|nop|mop|mnp|mno|
+---+---+---+---+
|bcd|acd|abd|abc|
|fgh|egh|efh|efg|
|jkl|ikl|ijl|ijk|
+---+---+---+---+

f"1"_  applies f to each rank 1 object (i.e. each vector) in the entire
argument; 0 2 1 3&|: transposes axes 1 and 2; and "box" boxes each matrix
to produce a compact display.

The following is a translation of definitions on p. 58 of "Some Uses of
{ and }", APL87 Conference Proceedings.  Here, we use the technique of
outfixes in place of complementary indexing, to compute the minors.
(f and minors are repeated from above.)

   f       =. 1 & ([\.)
   minors  =. (0 2 1 3&|:) @ (f"1"_) @ f
   det     =. -/ . *
   checker =. */~ @ ($&1 _1) @ #
   adjoint =. |: @ (checker * det@minors)
   matinv  =. adjoint % det

   [ n =. _40+?4 4$100
_27  35  5 13
_19 _36 27 27
 53  _2 11 43
_37 _35 12 27
   det@minors n
_21546 _49272   29140 _21394
_10227   4362 _170024 _55897
 20979  _3342  _24952 _44171
 33264 _33408  144316  76364
   checker n
 1 _1  1 _1
_1  1 _1  1
 1 _1  1 _1
_1  1 _1  1
   adjoint n
_21546  10227  20979  _33264
 49272   4362   3342  _33408
 29140 170024 _24952 _144316
 21394 _55897  44171   76364
   det n
2730084
   n +/ . * matinv n
           1 6.77626e_21 _1.35525e_20           0
_2.71051e_20           1 _4.06576e_20 1.35525e_20
 2.71051e_20 2.71051e_20            1           0
_2.71051e_20           0 _5.42101e_20           1


+------------------
| Sam Sirlin
| <1991May21.161641.18112@jato.jpl.nasa.gov>

In article <1991May19.053021.7840@yrloc.ipsa.reuter.COM>, hui@yrloc.ipsa.reuter.
COM (Roger Hui) writes:
]> The determinant has been implemented in J this week.  The determinant has
]> rank 2 (applies to matrices), and is recursively defined by expansion
]> by minors along column 0:
]>

This sounds interesting, but if I was given a matrix and told to take its
determinant, I would use LU or SV decomposition if the matrix was above
about 6th order. Isn't the minor calculation ill conditioned? If so then
isn't a built in determinant using minors missleading to naive programmers?


+------------------
| Roger Hui
| <1991May22.125919.1759@yrloc.ipsa.reuter.COM>

Sam Sirlin writes:

>This sounds interesting, but if I was given a matrix and told to take its
>determinant, I would use LU or SV decomposition if the matrix was above
>about 6th order. Isn't the minor calculation ill conditioned? If so then
>isn't a built in determinant using minors missleading to naive programmers?

The system will recognize the ordinary determinant -/ . * as a special
case, and use an equivalent but O(n^3) algorithm to compute it.  Having a
determinant operator encourages experimentation with generalized determinants.
For example:

   + / . *          permanent
   <./ . +          minimum cost in assignment problem
   +./ . *.         whether a Latin square is covered
   + / . *.         how many Latin squares are covered
   [   . (,&.>)     try it

All except the last are from K.E. Iverson, "Determinant-like Functions
Produced by the Dot Operator", Sharp APL Technical Notes 42, 1982 4 1.


+------------------
| Roger Hui
| <1991Dec4.033607.18271@yrloc.ipsa.reuter.COM>

[[NB. apd. this an answer to a message posted much later with the same title
           but I didn't have the original.
]]
Walter Spunde writes:

      IBM Technical Report TR 01.A845 APL2 PHRASES
      Computational Algorithms phrase 11-22
      should be described as

         Evaluating a 3 row determinant

      The phrase given does not apply to determinants of order greater than 3
      and will give erroneous results. It would be nice to see an algorithm as
      neat as the one presented for higher order determinants.


In J, f . g is the generalized determinant.  It has rank 2 (applies to
matrices), and is recursively defined by expansion-by-minors along column 0:

   f . g y   is   (0{"1 y) f . g  f . g minors0 y  if 0<#y
                  identity element of g            if 0=#y

The _dyad_ f . g plays a key role in this definition, thus motivating the
choice of the _monad_ f . g to denote the determinant.  -/ . * is the
ordinary determinant.  A model of it can be defined simply:

   minors0 =. (}."1) @ (1&([\.))
   det     =. 1: ` ({."1 -/ . * $:@minors0) @. (*@{:@$) " 2

"minors0" computes the minors along column 0 of its matrix argument.
It consists of two components:  1&([\.) computes outfixes (\.) of size
one with the identity function ([), successively suppressing each row;
}."1 -- behead (}.) each row -- drops column 0.  For example:

   m =. 4 4$'abcdefghijklmnop'
   m
abcd
efgh
ijkl
mnop
   1&([\.) m              }."1 (1&([\.)) m
efgh                   fgh
ijkl                   jkl
mnop                   nop
                                          $ 1&([\.) m
abcd                   bcd             4 3 4
ijkl                   jkl
mnop                   nop                $ }."1 (1&([\.)) m
                                       4 3 3
abcd                   bcd
efgh                   fgh                (minors0 m) -: }."1 (1&([\.)) m
mnop                   nop             1

abcd                   bcd
efgh                   fgh
ijkl                   jkl

"det" is in the form   0-part ` 1-part @. condition " 2
"2 specifies that the verb has rank 2 (applies to matrices).  "condition"
computes the signum (*) of the tail ({:) of the shape ($) and, depending on
whether it is 0 or 1, apply "0-part" or "1-part"; that is, apply "0-part"
or "1-part" according to whether or not the argument has zero columns.

"0-part" is just the constant function 1.  "1-part" is a _fork_, whose
tines are {."1 (the head of each row, i.e. column 0 of the matrix),
-/ . * (the _dyad_ of the inner product -/ and * (minus dot times in APL)),
and $:@minors (recursively applying "det" to the result of "minors");
that is, compute the inner product of column 0 and of the determinant
of the minors of column 0.

"det" exploits _anonymous tacit recursion_ using $:, a new feature in J
version 4; in older versions, $: must be replaced by "det".  Examples of
using "det":

   x =. ?5 4$100            y =. 2 2$ _466 _447 29 171
   x                        y
13 75 45 53              _466 _447
21  4 67 67                29  171
93 38 51 83
 3  5 52 67
 0 38  6 41
   det x                    det y
2763492                  _66723
   -/ . * x                 -/ . * y
2763492                  _66723

The following applications of the generalized determinant are from
K.E. Iverson, "Determinant-like Functions Produced by the Dot Operator",
Sharp APL Technical Notes 42, 1982 4 1:

   + / . *          permanent
   <./ . +          minimum cost in assignment problem
   +./ . *.         whether a Latin square is covered
   + / . *.         how many Latin squares are covered

In June of this year, during a visit with Professor Dickey at the University
of Waterloo, I defined functions "mminus" and "mtimes", which linked
to the Maple extended-precision minus and times, whence   minus/ . mtimes
is an extended-precision determinant.

Many of the ideas of this msg were discussed in msgs
   1991May19.053021.7840@yrloc.ipsa.reuter.COM
   1991May22.125919.1759@yrloc.ipsa.reuter.COM
previously posted to this group.



*========================================
# Basic Questions About J

+------------------
| Jon Freeman
| <51612@netnews.upenn.edu> 24 Sep 91

I started reading comp.lang.apl about a month ago, only to discover that
it has been transformed into "comp.lang.j" :-).  I am THIS close to
buying a book on J, but posting my questions costs me nothing, so...

Here's my main question: Assuming that we should think of J as a step
up from APL, what are the major improvements?  More specifically,

1.  Are functions first-class data objects in J?

2.  Is any type-checking done when functions are loaded or typed in?

3.  Abstraction and hiding information:

  a.  Is it possible to make a variable visible to a small subset
      of functions and no others?

  b.  Is it possible to hide the body of a function from all but
      a few people?

  c.  Does J support abstract datatypes?

                                Thanks,


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

Jon Freeman:
   1.  Are functions first-class data objects in J?

Well, they're first-class objects in J.  [You can get on quite fine
without considering them data, however.]

   2.  Is any type-checking done when functions are loaded or typed in?

Yes and no.  This question does not map well into J's design.  As a
general rule, empty functions [those which have no domain] are
perfectly valid in J -- you just can't apply them to any data.

On the other hand, meta-functions (often used to construct functions)
are eager, and will complain if they can not deal with their
arguments.  But you can make them evaluate [parse] lazily, which of
course delays any error reports.

   3.  Abstraction and hiding information:

     a.  Is it possible to make a variable visible to a small subset
         of functions and no others?

Well, you can build functions with embedded constants.  If you like,
you could rebuild these functions on the fly every time this value
changed [thus achieving a 'variable' visible to a small subset of
functions].

     b.  Is it possible to hide the body of a function from all but a
         few people?

Sure, only let a few people access the machine on which it is running.

Or, build the function on the fly using mysterious methods which you
don't divulge.  This will likely cost you in efficiency, though.

Personally, I hope it is a while before "anti-documentation" features
are added to the language.  (I would agree with the GNU people on this
point, that hiding the source code to a program which you distribute
is anti-social.)

     c.  Does J support abstract datatypes?

Well, yes and no.  If you consider 'type' to be a form of data, then
yes.  If you consider type to be something with syntactic properties,
then you only have the built-in object classes.

As an example of how one might deal with enumeration types, for
instance, here's a part of an example more or less swiped out of the
'Programming in J' book.  [ObPlug: it's a good book.  It somehow
manages to cover more ground than books massing 10 times as much.]
(Btw, I'm going to add comments, since you may not have a copy of J
handy to try out variants.)

   [ colours =.;:'Red Orange Yellow Green Blue Violet'
+---+------+------+-----+----+------+
|Red|Orange|Yellow|Green|Blue|Violet|
+---+------+------+-----+----+------+
   [ primaries =. 0 3 4 { colours
+---+-----+----+
|Red|Green|Blue|
+---+-----+----+

Ok, so far we've established our referent data, and shown that there
is a mapping from integers to names.

   index =. colours&i.
   [ k =. index primaries
0 3 4
   index^:_1 k
+---+-----+----+
|Red|Green|Blue|
+---+-----+----+

Here, we've established a mapping from names to numbers.  Also, we've
established that this is operation is easily reversible.

   next =. >:
   next k
1 4 5
   next &. index primaries
+------+----+------+
|Orange|Blue|Violet|
+------+----+------+

This shows that numeric increment can be applied to our 'enumeration
type' by using the equivalence between names and numbers.

   after =. next&.index
   after colours
+------+------+-----+----+------+---+
|Orange|Yellow|Green|Blue|Violet|Red|
+------+------+-----+----+------+---+
   after^:2 primaries
+------+------+---+
|Yellow|Violet|Red|
+------+------+---+
   after^:_1 primaries
+------+------+-----+
|Violet|Yellow|Green|
+------+------+-----+

And, finally, we can encapsulate the successor function and use it in
a generic fashion.  By the way, you could set things up so that
'after' crashes [gives a domain error] if you try to find the
successor to Violet or the predecessor to Red.  However, it is likely
that this will just add a bunch of complexity without accomplishing
anything useful.

I suppose you could say that the essence of J is making useful things
easy to accomplish.


+------------------
| Robert J Frey
| <619@kepler1.kepler.com> 27 Sep 91 19:22:37 GMT

In article <51612@netnews.upenn.edu> freeman@gradient.cis.upenn.edu (Jon
 Freeman) writes:
>Here's my main question: Assuming that we should think of J as a step
>up from APL...

Although most of my recent posts on J have been critical (I hope in the
positive sense) of some of its features, I am certainly a strong supporter
of the language and belive it is a definite step up from APL!

>... what are the major improvements?  More specifically,
>
>1.  Are functions first-class data objects in J?
>
Functions can be defined tacitly, e.g., using a form known as a "fork" you
can define a "mean" function:

        mean =. +/%#
        mean
+-----+-+-+
|+-+-+|%|#|
||+|/|| | |
|+-+-+| | |
+-----+-+-+

        mean 0 1 2 3 4 5 6 7 8 9
4.5

The language also has "gerunds", i.e., verbal nouns, which can be manipulated
like nouns but executed like verbs.

Whether this qualifies calling them "first-clas" objects I don't know.

>2.  Is any type-checking done when functions are loaded or typed in?
>
There is certainly a notion of each verb, adverb and conjunction having a
domain, but there really isn't very much type checking going on.

>3.  Abstraction and hiding information:
>
>  a.  Is it possible to make a variable visible to a small subset
>      of functions and no others?
>
>  b.  Is it possible to hide the body of a function from all but
>      a few people?
>
>  c.  Does J support abstract datatypes?
>
I had proposed something to the people at ISI which would allow for
this sort of thing. The language at present doesn't permit it.

The idea is to introduce the notion of a subspace. Thus, a reference like

        space.message argument

would send the "argument" to "message" in "space". The thing called "message"
could be any J object. If "message" were a noun for example, then
"space.message" would simply return its value. The key is any execution that
took place would occur within the "space" subspace: the arguments (if any)
go in, the results come out, but the world inside is otherwise veiled.

Objects that were to be strictly local would be referenced with an initial
period. Thus, ".data" would a strictly local pronoun not available outside
its native context. In this way the public and private elements of a subspace
could be defined and referenced.

Subspaces would be referenced with a final period. Thus, "space." refers to
the whole subspace "space".

This simple extension (just nested symbol tables really) would allow you to
define data types (e.g., nouns with property lists/structures with
fields), program libraries (a la Ada type modules), static nouns in verbs
without using globals, and simple object-oriented programming by binding
data and functions together into a single object.

Within only a little more work one could introduce a full objected oriented
capability into the language, including real abstract object classes, multiple
inheritance, etc.

This material is currently in a paper I am preparing for publication. As I said
earlier I've corresponded with ISI a little on these ideas. If anyone else is
interested or is interested in seeing a preliminary version of the paper let
me know.

+------------------
| Gfeller, Martin
| <1991Oct7.163814.414@yrloc.ipsa.reuter.COM>


I think the main emphasis in J development has been on expressiveness,
and not on easier construction of large programs.

APL is weak in information hiding and data abstraction, and J doesn't depart
a lot from APL in that area. In my opinion, APL/J need a big push into that
direction in order to be viable languages with a future.

Combining APL/J with OO paradigms could solve many problems, without lowering
expressiveness. On the other hand, simply adding a type system could lower
the expressive power of the language considerably.

/Martin


+------------------
| Robert J Frey
| <622@kepler1.kepler.com> 9 Oct 91 15:43:40 GMT

In article <1991Oct7.163814.414@yrloc.ipsa.reuter.COM>
 mgf@ipsaint.ipsa.reuter.COM (Gfeller, Martin (zurich K6,network Prod)) writes:
>
>I think the main emphasis in J development has been on expressiveness,
>and not on easier construction of large programs.
>
>APL is weak in information hiding and data abstraction, and J doesn't depart
>a lot from APL in that area...
>
>Combining APL/J with OO paradigms could solve many problems, without lowering
>expressiveness. On the other hand, simply adding a type system could lower
>the expressive power of the language considerably.
>
I could not agree more. In my early posting I alluded to some material I had
sent to ISI regrading OO extensions to J and about which I am in the process of
preparing a paper for publication.

I was very concerned with extensions that would not destroy the basic character
of the language. Thus, a "type" system was out of the question. In the first
part of the paper I, in fact, agonize over the philosophical issues of how
one should make such extensions.

I introduce OO capability in two passes. The first defines the concept of
a subspace withing the context of the existing language, i.e., introducing
only a single notational convention and no new operators. I show that
this is sufficient to give subspaces a level of capability somewhat less than
true objects (as in Eiffel) but somewhat more than modules (as in Ada).
The second pass introduces two new operators whose domain and range are
subspaces rather than parts-of-speech. This gives the language true objects
without compromising its character.


+------------------
| Gillett, David
| <1991Oct14.172013.28498@yrloc.ipsa.reuter.COM>


>I introduce OO capability in two passes. The first defines the concept of
>a subspace withing the context of the existing language, i.e., introducing
>only a single notational convention and no new operators. I show that
>this is sufficient to give subspaces a level of capability somewhat less than
>true objects (as in Eiffel) but somewhat more than modules (as in Ada).
>The second pass introduces two new operators whose domain and range are
>subspaces rather than parts-of-speech. This gives the language true objects
>without compromising its character.


     The notion of subspaces is a particularly powerful one.  Hardware
permitting, non-overlapping subspaces might be hosted on multiple processors;
perhaps this will allow us to express MIMD parallel algorithms as easily as we
can already express SIMD vector algorithms....


 