(summary.txt)
a) History.
   When I got exposed to J about 3 years ago it appeared to me as a curiosity,
   interesting to study but fustrating to use, as error messages at that time
   where not very helpful or not existing. My next exposure came at a seminar
   conducted by Prof. D.B. McIntyre in Toronto on Sept. 28 1992. This seminar 
   convinced me, that after all, J became a viable alternate to A.P.L.
   The A.P.L. I was using was STSC APL*PLUS for the PC. and I was looking
   around for a replacement. As I am retired, computing is now a hobby and
   a $1000 replacement could not be justified. J was priced right and also
   included all desired developments such as nested arrays and windows 
   compatibility, so I decided to switch. 
b) Programming style. 
   As my background is in Engineering Economics  applied to Transportation 
   Planning,I am not a programmer, evenso I have used computers heavily since
   the early sixties and had several programmers reporting to me. 
   I tend to take liberties with programming standards as long as it gives me 
   the required results, if I can not achieve my goals other wise.
   For instance when developing the J-lib programs I used "go to labels" 
   heavily as I am not comfortable with the gerund constructs.
   I have seen nowhere the statement: THOU SHALL NOT USE GO TO so I went ahead
   regardless if Prof. Dykstra might not like it. On the other hand I check 
   always code with labels to see if alternate ways are possible and incorporate
   them, then or at a later date. The result is that my code looks more like APL
   then it should, but it allowed me to progress faster. 
c) People familiar with STSC APL*PLUS will recognise the segmented strings
   programs such as pullsg, putsg etc. These verbs combined with the use of
   verbs seltoken,selsep,m2s and s2m give an added dimension to APL and here 
   to J. They allow the storing of character-tables as segmented strings of 
   characters and allow easy retrieval using verbs s2m and m2s. Also verb 
   asc2j retrieves an asci file into a J-table , using these segmented 
   string verbs. 
d) I decided to develop J-lib as an exercise to see if an alternate to
   workspaces could be designed that has the functionality of workspaces
   but not the disadvantages of duplicated storage of verbs.
   As usual it took a lot longer to develop than expected and represents 
   about 6 man-months of work. One side effect was that it became clear that
   J needed a lot more tools to allow a programmer to debug and test his code.
   This is very important to beginners and intermediate programmers as otherwise
   the learning curve is a long and time consuming one, even for A.P.L ers.
   The verb "testof" described in tutorial "tu5" speeds up development
   of J-code by a factor of 5 to 10.
e) The status of J-lib at this stage is that it achieved the goals discussed 
   in item d) above. The development also made me aware of some problems
   ahead. If the J-lib system is used to collect a lot of code, for instance
   to build up a Finnapl type of idioms files by collecting this code on the
   Internet, then duplication of verb names and to a lesser extent duplication
   of local and global noun names is a problem. See tu4 for details on this.
f) The development of programs to manage the code in a J-lib is not fully 
   completed yet. Still required are programs to remove obsolete verbs from the
   library. Verb cleanup is a start for this process. 
   Till September(94) I am committed to other things so this must wait.
   