9/494-498 Mitcham Rd., Mitcham, Victoria 3132, Australia. 27/2/88. Dear Mike, I have taken an interest in the structure of LEX files and have come up with five new keywords which may interest you. In order of writing, they are: KEYWORD$, then HITOKEN, ID and LOTOKEN together, and finally, LISTLEX$. The parameter for KEYWORD$ takes the same form as MSG$; in fact, it can use the output of TOKEN from SCANLEX. Incidentally, ENTRY$ has been invaluable in using the DEBUGGER - setting the faulty keyword's entry point as a break- point. The main purpose, for me, of the function KEYWORD$ was to tell me if a particular ID/Token combination was already in use in my Titan. In fact, originally, I had it as a statement USED? which simply displayed "ID/Token used" or "ID/Token Available". I then thought, if they were used, what was the keyword? This is why I have not bothered to handle the ID 00, as we all know that all the tokens with that ID have been used. Once KEYWORD$ was written, I realised that the next three keywords could permit a very short, simple and rapid BASIC program to replace LISTLEX from a early swapdisk (563 bytes, no special keywords, but could not handle links). The two lines below do all that LISTLEX did with less bytes needed: 10 INPUT "Filename?";F$ @ I=ID(F$) @ DISP F$;" ID=";I @ I=I*1000 20 FOR J=LOTOKEN(F$) TO HITOKEN(F$) @ DISP KEYWORD$(I+J) @ NEXT J With a little more effort, we could also cope with linked LEX files. After all that I had learned from these two files, I thought "Why not do the whole LISTLEX in one keyword?"; and LISTLEX$ is the result. Naturally there were many mistakes and blunders along the way, but with the help of the DEBUGGER, I finally worked it all out. I presented it at our February PPPM meeting and it had good acceptance. Two of the members unfortunately discovered the hard way ("Memory Lost") that LISTLEX$ should not be used on the DEBUGGER LEX files. Some of HP's more obscure files may also have that problem. Note that there is no check for sufficient memory to write LISTLEX$ to the stack. Hopefully, for most people, this should not be a problem; for example: LEN(LISTLEX$("MATHROM")) is less than 700 bytes. The keywords other than KEYWORD$ all take a LEX filename as sole parameter, perform tests of validity ( filespecifier, filetype from E208 & E20B), then go on. The output of LISTLEX$ is best seen by trying it out. The O/P string contains carriage returns and line feeds to facilitate displaying and printing. It can thus be printed on the thermal printers as well as the THINKJET, but for best results, WIDTH and/or PWIDTH should be set to INF. I am still seeking assistance with the handling of arrays in assembler. You will recall HORNER which evaluates polynomials. It would be so much better to have the function in the form: HORNER(A,X) where A is the array A(N) of polynomial coefficients and X is the value at which it will be evaluated. There are other functions of arrays that I wish to write to make easier the statistics I do. Any help would be most gratefully accepted. All that I write will become readily available to you, whether from these occasional communications, or through Technical Notes (which I hope you are still receiving-though there is no Nú 22 - the printer lost it) or perhaps through your swapdisks. My best wishes to you for a happy and prosperous New Year, Happy Programming from "down under", Jack Elhay. Postscript,13/7/88. I have tried to interest others in the club (PPPM) in making more contributions both to TN and to swapdisk. I held off sending this in the vain hope that more would be forthcoming. I am hopeful that some material may be available from Sydney. Meanwhile, I have added some more files to send to you. You will see how much better MCURSOR is than VCURSOR - still learning and just turned 50 years young. There is one member from whom we will not hear again. Bob Laughton died in his sleep recently. You will remember his contributions in swapdisk 7 and in TN; requiescat in pace. Jack.